|
Kind of a bandaid over a lovely setup, but couldn't NPM just put something like "if you host your package on NPM and its used, you can only archive your package, not remove it", and solve these sort of issues? Or even just let them delete it, but keep it up for thirty days or something to give people time to replace. Waking up to something just being gone is pretty insane.
|
# ? May 27, 2019 22:01 |
|
|
# ? Jun 6, 2024 02:27 |
|
ddiddles posted:Kind of a bandaid over a lovely setup, but couldn't NPM just put something like "if you host your package on NPM and its used, you can only archive your package, not remove it", and solve these sort of issues? But maybe npm lets actual npm-hosted packages just wander away too, I don't know.
|
# ? May 27, 2019 22:10 |
|
Ola posted:Camera zooms out. That was just one brick. Zooms out more. A brick in the support column of a huge bridge. Zooms out even more. In a vast metropolis of brick structures. The only solution is to take down the metropolis.
|
# ? May 27, 2019 23:53 |
|
roomforthetuna posted:But maybe npm lets actual npm-hosted packages just wander away too, I don't know. They supposedly changed their policies after the left-pad incident to only allow de-listing of published versions, after I think a 24 hour period. If I recall there was an event shortly after left-pad where this was ignored.
|
# ? May 28, 2019 00:01 |
|
ddiddles posted:Kind of a bandaid over a lovely setup, but couldn't NPM just put something like "if you host your package on NPM and its used, you can only archive your package, not remove it", and solve these sort of issues? Yeah, they did this after the left-pad fiasco. If a package is published more than 72 hours ago you cannot unpublish it. This most recent incident was only npm's fault in the sense that npm allows you to specify an url as a dependency rather than a package name and version. The url that some packages had in their package.json stopped working, so those packages stopped working, and packages that depended upon them stopped working, and packages that depended upon them stopped working, and packages that depended upon them stopped working, and packages that depended upon them stopped working, and packages that depended upon them stopped working...
|
# ? May 28, 2019 00:21 |
|
Doom Mathematic posted:* proactively converts str to a string if it isn't a string for some reason Because it might be a Number
|
# ? May 28, 2019 15:59 |
|
code:
|
# ? May 28, 2019 16:10 |
|
Man I've taken this whole ecosystem for granted, was under the impression that NPM packages could only depend on other hosted npm packages. Allowing just a url to something that can disappear is...wtf.
|
# ? May 28, 2019 17:05 |
|
Nolgthorn posted:The method is built into javascript. padStart That too lol I've had the same realization about parts of engines like JQuery so many times that I don't feel like I'm missing much at all by being wholly adverse to importing outside code
|
# ? May 28, 2019 17:22 |
|
The String method was added in ES2017, so it's relatively new. The left-pad debacle happened before it was introduced.
|
# ? May 28, 2019 18:04 |
|
Dumb Lowtax posted:That too lol Yeah, the big problem when evaluating libraries is knowing what to reuse and what you should write yourself. There's always a cost when using a third party library - it can be difficult to assess how well you understand the problem the library is trying to solve, dependency management can be a huge bitch, and it can be difficult to assess how well tested the library is or whether it's handling cases that are pertinent to your problem domain. I would say new developers or developers fresh out of school are generally going to use every library under the sun and then get burned when a problem comes up that's difficult to explain because it in no way relates to your problem domain, but is just a consequence of including every library under the sun. This jades people and turns them into "gently caress it, write it myself" types - these types get burned when they try to fix issues or make their own (crypto, deserialization/serialization, authentication, XSS, input sanitization etc.) Judgement eventually gets better through experience.
|
# ? May 28, 2019 18:20 |
|
Bruegels Fuckbooks posted:Judgement eventually gets better through experience. Well...if its going to get better that's how it happens. There's plenty of old farts around that insist on rolling every. single. thing. themselves.
|
# ? May 28, 2019 19:53 |
|
I don't plan on doing it forever, you all have convinced me to at least start looking around for solutions when I get to "authentication" being something my engine has to do
|
# ? May 28, 2019 20:02 |
|
I know "this" binding is weird in React, but I thought arrow functions fix most of those problems? I've got this:code:
|
# ? May 28, 2019 21:12 |
|
this is pointing at the React component / function scope. You should _never_ change element properties using e.g. `el.src` in react. You need a piece of state that you change on click. untested code but the right idea: code:
necrotic fucked around with this message at 21:18 on May 28, 2019 |
# ? May 28, 2019 21:15 |
|
necrotic posted:this is pointing at the React component / function scope. You should _never_ change element properties using e.g. `el.src` in react. You need a piece of state that you change on click. That might not work because this is in a mapped array with sometimes dozens of images, and that won't work unless each has its own unique useState, right? Is there a place I can show code for a critique/suggestion? I made something functional that I'm proud of, but I've only been teaching myself React for about a month so I'm sure I've made a bunch of mistakes or didn't do things the React way. It's been about two months since I've thought about using Javascript for more than simple DOM manipulation.
|
# ? May 28, 2019 21:38 |
|
Yeah, the small snippet you gave doesn't really provide any context. What's the overall goal?
|
# ? May 28, 2019 22:01 |
LifeLynx posted:That might not work because this is in a mapped array with sometimes dozens of images, and that won't work unless each has its own unique useState, right? Jsfiddle or glitch.io are common places to put demo code, or github.io if you want it more associated with you.
|
|
# ? May 28, 2019 22:12 |
|
I feel like I'm doing something wrong with this web worker I'm writing. So, the basic gist is that, the web worker is used to connect to IoT devices on your LAN, and send commands over TCP. We want the commands to be as concurrent as possible, so just rapid-fire send them off. I chose a web worker as I can write pure javascript for this logic and only post a message to it from the accompanying Electron UI when necessary. I have the web worker set to basically wait a second if the queue is empty, so that if commands are queued in that second, it can rapid-fire execute the commands. This works great, except it's a recursive call, so it hits the call stack limit pretty quickly. I feel like I'm doing something very wrong here. There's probably a design pattern I'm missing, but I got gently caress all for a true computer science education despite having a degree in comp sci. The processing method is this: code:
If a library for this exact thing exists on NPM, that's also an option. The less code for this poo poo I have to write the better, since surely someone else has figured this out in a better way than I have.
|
# ? May 28, 2019 23:55 |
|
Two options I see: 1. Use a loop instead of recursively calling. 2. Always use setTimeout, but change the delay to 0 if the queue is not empty. edit: also, is a first-in-last-out queue the right option here? Using shift instead of pop is more common for something like this. edit2: also, the first option i gave would also hit the stack limit you just need to go with the second option, which always resets the stack. I'd do something like this: code:
necrotic fucked around with this message at 01:40 on May 29, 2019 |
# ? May 29, 2019 00:58 |
|
It did used to be in a setTimeout so it makes sense that when I got rid of that in the final call that I started getting the error. It doesn’t really matter what direction the queue is, I can change that. I just didn’t know if there was some other way I could just kick off a loop that processes the queue. I almost thought about kicking off another worker and sending messages to that, but that seems like overkill.
|
# ? May 29, 2019 01:58 |
|
I have almost nothing but scientific computing experience and just finished my first javascript experience last week, so I've got a stupid question. I'm working through this react tutorial building a movie database table where we can delete table entries. The below portion, within the handleDelete method, is what I'm curious about. Within the filter method, the arrow function is defined using the 'm' symbol. What is this symbol referencing? the _id is a property of the movies array of objects that the getMovies() function returns, so I get that it's pulling from that, but how does it know? For that matter, what is the `this` symbol referencing here? This confuses me in class context. code:
|
# ? May 30, 2019 02:32 |
|
Kudaros posted:I have almost nothing but scientific computing experience and just finished my first javascript experience last week, so I've got a stupid question. If you call Array.filter() on something, it invokes the function you provide on every element in the array, and the return value is an array containing the elements that passed the test. You are naming the argument that you're providing though - filter function itself doesn't care what the arguments are named (e.g. you could could it 'movie' instead of 'm', or 'value'... doesn't matter as long as you provide a function with expected number of arguments for filter). For "this", check how "Component" is defined in react...
|
# ? May 30, 2019 02:48 |
|
I don't know React but generally when I see a "class" in JavaScript, the "this" keyword appearing in method-scope of that class refers to an instance of that class, so it looks like your "this" is an instance of a "Movies" which I guess wraps all your movies.
|
# ? May 30, 2019 02:58 |
|
"this" in a class context is the instance, yes. Static members would be Movies.whatever, not this.whatever.
|
# ? May 30, 2019 03:06 |
|
Ah I see. It's becoming more intuitive now, thanks. I'll spend more time on the docs.
|
# ? May 30, 2019 04:04 |
|
For anyone else who might be doing some queue-based processing work I was previously confused about, I discovered this package: https://yarnpkg.com/en/package/queue I turned on the autostart option so that it fires off the tasks as soon as they're entered into the queue, and this is immediately noticeably faster than my home-grown method. Plus, it let me cut out about half of the code that I wrote to manage the queue that was also probably wrong. So, thanks for your help necrotic, your code did help me out a bit, but this seems to be the best solution for my specific use case.
|
# ? May 30, 2019 16:50 |
|
Protocol7 posted:For anyone else who might be doing some queue-based processing work I was previously confused about, I discovered this package: Oh that reminds me - I bet RxJS would handle it pretty well, too, but it's got a lot more going on than a queue.
|
# ? May 30, 2019 17:38 |
|
tankadillo posted:I recently changed my React app to store parts of its state in indexeddb (via LocalForage). Components use a useEffect hook to load their state from indexeddb and then a useEffect hook to write changes any time the state updates. This seems to be working fine, except I can't figure out how to get my tests to play nicely with it. (I'm using react-testing-library.) I assume I should use something like waitForElement to wait for the state to load (since indexeddb is async), but Jest gets mad at me because I don't have all my state changes wrapped in act(). The problem is, I can't easily change `const {getByText} = render(<MyComponent/>);` to `const {getByText} = act(() => render(<MyComponent/>));`, or can I? In case anyone cares, I solved this problem by creating a manual mock for my hooks which removes all the async functions. It won’t actually test the storage, but 99% of what I’m testing is how the data gets processed, not stored, anyway.
|
# ? Jun 2, 2019 14:26 |
|
I'm adding webhook functionality to a rails app. At the moment I just have the one channel and inside the receive function I use the data passed to it to dispatch a custom event (something like "webhook:modelNameActionName"). This way I can just use event listeners inside the .js files relevant to that modal to trigger the desired behaviour. It all works fine and seems tidier this way to me than putting the desired behaviour logic right there in the receive function, but I was just wondering if there's any reason I shouldn't be doing it this way? I'm not too clued in on JavaScript best practices but it feels like adding dozens of listeners might not be great?
|
# ? Jun 4, 2019 11:09 |
|
What are yall using for typescript linting? Is eslint ready to replace tslint yet in practice?
|
# ? Jun 4, 2019 15:49 |
|
Chas McGill posted:What are yall using for typescript linting? Is eslint ready to replace tslint yet in practice? Im still on tslint/tsc and haven't felt enough pain to think about switching back to eslint.
|
# ? Jun 4, 2019 16:07 |
|
Just end my life with these "event listeners don't force React to rerender" problems.code:
Edit: Wait, it forces an update... but is passing on the OLD data ("DoNotUse") to Firebase. How can I get it to send the new data? LifeLynx fucked around with this message at 20:44 on Jun 4, 2019 |
# ? Jun 4, 2019 20:37 |
|
code:
Have a useEffect watching gameName and react to it changing, you could have your form just call setGameName("WhateverGameName"), and a useEffect that calls GenerateStacks.
|
# ? Jun 4, 2019 21:08 |
|
ddiddles posted:
Oh that's interesting. Coincidentally this is for a Magic: The Gathering type thing, and in Magic there's a group of rules called "state based actions" that watch for a state change and something happens (usually a player losing the game or a creature dying) as a result of it. They aren't checked in the middle of a spell resolving though, instead they wait for a spell to resolve and see whether or not they should happen... I'm starting to see programming logic everywhere. How would I write this useEffect though? I've only ever used them for triggering an action once as in the example code I posted.
|
# ? Jun 4, 2019 21:17 |
|
Untested but something like this should work, really depends on what GrabData is doing. The second argument to useEffect is an array of variables react will watch and call the passed in function if any of them have changed (shallow check, no deeply nested stuff), giving it an empty array says "there are no dependencies, so run this on first render", the one below will call GenerateStacks every time gameName changes. code:
ddiddles fucked around with this message at 21:24 on Jun 4, 2019 |
# ? Jun 4, 2019 21:20 |
|
I can’t help but feel like hooks are making this more complicated than the old way of doing it.
|
# ? Jun 5, 2019 02:35 |
|
smackfu posted:I can’t help but feel like hooks are making this more complicated than the old way of doing it. I feel this way almost every time I see examples of code using hooks, but to be fair I haven't had the time to really dig into them.
|
# ? Jun 5, 2019 03:08 |
|
smackfu posted:I can’t help but feel like hooks are making this more complicated than the old way of doing it. I think they are not more complicated, but they are new enough and just different enough to cause issues when you bring your old mental model along with you when starting to use them. Plus there’s the ‘new and shiny’ factor so people are trying to cram them in even when maybe they didn’t need to.
|
# ? Jun 5, 2019 03:30 |
|
|
# ? Jun 6, 2024 02:27 |
|
Hooks make some things more complicated, but they're real nice for being able to combine componentDidMount and componentDidUpdate logic and derived data stuff in a way that cares less about the overall lifecycle of the component.
|
# ? Jun 5, 2019 04:41 |