281–290 of 336 posts
Earlier quoted context omitted.
> Anything wrong with that? It only works in browser environments.
Node has EventEmitter: https://nodejs.org/en/learn/asynchronous-work/the-nodejs-eve... See, for instance, https://www.electronjs.org/docs/latest/api/ipc-renderer
Earlier quoted context omitted.
I've literally never needed to do that. What's a real world use case?
Doing multiple async tasks concurrently as opposed to in sequence. If you have never used this you have either worked on extremely simple systems or have been leaving a ton of perf gains on the table.
Earlier quoted context omitted.
Functional usually means the output can only depend on the input. But this is depending on some external state getting smuggled in through a hook. FWIW some people prefer the alternatives over this.
This not really correct, the useReducer hook is not some external state which is smuggled in. It is an actual input for the reconciler which defines an output of this component, so it is perfectly functional even by your definition.
Earlier quoted context omitted.
I've literally never needed to do that. What's a real world use case?
I often map a series of X to Y with Promise.all. For example, mapping a series of image URIs to loaded Image elements. It is shorter to write than a for of loop, and importantly, all images will be loaded in parallel rather than sequentially, which can be significantly faster. images = Promise.all(uris.map(loadImage))
Earlier quoted context omitted.
You could work for 50 years and never need those… it just depends on what you’re creating / how many devs and so on. I know some guys who over the years wrote their own framework. It works great… for them.
Right, the only thing that convinces me is team and hiring dynamics. But that’s not what these tools advertise. It’s always like: you have dozens of interactive controls in this view, it’s getting out of hand, you should use this language that compiles to HTML and JavaScript and carry all these dependencies. To which I always reply: no thanks, I rather deal with the dozens of controls.
And that's fine, these tools don't solve what you search for.
A dozens of controls multiply with a dozens of events are already a quite big amount of points of failure, so people gladly trade it with the dependencies (what's the issues with dependencies anyway?).
So yeah, not many people want to be good, and only hire good people like you to use the hand tools and "just do it correctly". Most acknowledge their downsides and use proper tools to aide them.
Earlier quoted context omitted.
This is an interesting topic so I tried to dive in a bit. From my reading I understood that Qt signals & slots (and Qt events) are much more closely related to JavaScript events (native and custom). In both you can explicitly emit, handle, listen to events/signals. JavaScript events seem to combine both Qt signals & slots and Qt events. Of course without the type safety. For example, taken from https://doc.qt.io/qt-6…
This sounds interesting. The code examples reminded me of Qt signals but all the answers to my post suggest that JS signals would be much more powerful. Honestly, I'd need to take a closer look.
You can think of reactive signals as combining an underlying event system with value construction, ultimately defining an object graph that updates itself whenever any of the parameters used to construct it change. You can think of this graph like an electronic circuit with multiple inputs and outputs, and like a circuit, the outputs update whenever inputs change.
When I need to signal something across my application, I use events: window.dispatchEvent(new Event('counterChange')); And every part of the application that wants to react to it can subscribe via window.addEventListener('counterChange', () => { ... do something ... }); Anything wrong with that?
window.addEventListener('counterChange', () => {
element.innerHTML = 20components.map(|c| c.renderHTML(newCounterValue)).join('');
});
Also, multiply the number of events to the number of components can make the application go out of hand very quickly.
When I need to signal something across my application, I use events: window.dispatchEvent(new Event('counterChange')); And every part of the application that wants to react to it can subscribe via window.addEventListener('counterChange', () => { ... do something ... }); Anything wrong with that?
The problem with events handling are, you don't actually know what needs to be done when the event trigger. Let's say you have 20 components, on counterChange, which of the 20 components need to be updated? And how? You can either do it the simple (and very inefficient), and it's React conceptually way by render all 20 of your components again with new value of counter, i.e. window.addEventListener('counterChange', (…
Earlier quoted context omitted.
Signals have, too. And it is literally spelled out in the readme, in the introduction section
They did create a polyfill, but the readme says it was based on design input from other projects, not on aligning multiple existing designs. This at least sounds like the opposite of what happened with promises, where they already existed in multiple libraries before the Promises/A design came out.
Signals exist in multiple libraries with what are really minor variations on the theme.
> before the Promises/A design came out.
That's why the current proposal asks for input about design.
IIRC, promises also had multiple iterations on the design. There were calls to make them more monadic, less monadic, cancelable, non-cancelable etc.
And the original proposal looks nothing like the eventual API: https://groups.google.com/g/commonjs/c/6T9z75fohDk [1]
And new things are still being added to them (like Promise.withResolvers etc.)
[1] There's a great long presentation on the history of promises here: https://samsaccone.com/posts/history-of-promises.html
Earlier quoted context omitted.
>> Getters and setters work pretty well. What do you mean can you explain more?
Sure. I structure my apps with light DOM vanilla web components, using lit-html (not lit) as a renderer. I'll use a hypothetical patient profile component as an example. Let's say that it's a top level "page" and needs to support deep linking. set patient_id(value) would trigger a loadPatient(). loadPatient would set this.patient when loading is complete. The setter for this.patient triggers a render and paints the c…
- don't forget to trigger a render from a getter. Possibly not just from one getter if the component relies on more than one data point that is changing
- don't forget to fire a custom event if this data needs to be propagated somewhere else
- don't forget to subscribe to the custom event in the places where this data is needed and trigger the render when the data is updated
- (good programming practice: ) don't forget to unsubscribe from those custom events because memory leaks
I'm not saying it's impossible to do, or that people haven't been doing this, successfully, for years across many projects. What you can have though is that same thing happening automatically: when a reactive value gets updated, all the places where it's used get updated. As frameworks/libraries with fine-grained reactivity will show you, literally only those places will get updated. E.g., you won't need to re-run a full re-render on an entire component just because some piece of data got changed.