141–150 of 336 posts
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?
Am I the only one that thinks the vanilla js example is actually easier to read and work with? - "The setup is noise and boilerplate heavy." Actually the signals example looks just as noisy and boilerplate heavy to me. And it introduces new boilerplate concepts which are hard for beginners to understand. - "If the counter changes but parity does not (e.g. counter goes from 2 to 4), then we do unnecessary computation…
Why do you think this is premature memoization? This is an example, boiled down to a simple function. Do you think people just came up with the use case for this without ever having needed it? I think an effort in standardizing signals, a concept that is increasingly used in UI development is a laudable effort. I don't want to get into the nitty gritty about what is too much boilerplate and whether you should build a…
You're basically saying you want this thing, but you don't want to have to justify it
Looks useful, but what baffles me is.. Why is every framework setting state or their "signals" using "setX" functions? What's wrong with the built in getter and setters that you can either proxy or straight up override? This feels arguably cleaner: something = "else"; Than: setSomething("else");
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?
If you mis-type ‘countenChange’ it could be quite frustrating!
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?
> Anything wrong with that? Well, don't events only bubble upwards? You need to know the exact element of it is not on a lower level in the DOM tree. Events were too messy, so I wrote a small pub/sub message queue type of thing. Anyone anywhere in the DOM can subscribe to messages based on subject regexes. Makes things a lot easier, especially when I added web components to wrap existing elements so that publishing a…
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?
If you mis-type ‘countenChange’ it could be quite frustrating!
Earlier quoted context omitted.
> How does effect knows that it needs to call this lambda whenever parity gets changed? The call `parity.get()` will register a dependency on the function that is passed to `effect()`. When `parity` is updated, the function is called. > Will it call this lambda on any signal change? Only when a dependent signal changes. In this case, `parity` depends on `isEven` and `isEven` depends on `counter`. So when `counter` is…
This works well until you accidentally have an if/else branch, then you get hard to track bugs (halting problem in the general case). I'm guessing this is why they don't propose to add this function to the standard: That fact makes it not very pretty.
Earlier quoted context omitted.
> How does effect knows that it needs to call this lambda whenever parity gets changed? The call `parity.get()` will register a dependency on the function that is passed to `effect()`. When `parity` is updated, the function is called. > Will it call this lambda on any signal change? Only when a dependent signal changes. In this case, `parity` depends on `isEven` and `isEven` depends on `counter`. So when `counter` is…
This works well until you accidentally have an if/else branch, then you get hard to track bugs (halting problem in the general case). I'm guessing this is why they don't propose to add this function to the standard: That fact makes it not very pretty.
Earlier quoted context omitted.
I've been using patterns like this for more than a decade. The thing that's hard is, down the road you could have a listener, which triggers a other event, then another event, which comes back to the first routine and now you got a listen-loop that won't quit. And it's hard to ensure that all listener don't cause that trigger cascade.
Isn't it possible to define all listeners / publishers in a declarative way which can be compiled to catch for this issues?
In fact, the GOF spend an entire paragraph on the problem of complex update semantics in "design Patterns" (1995) ch Observer p299.
So, while it is a real problem, it's one that has been solved (for at least 29 years)
Am I the only one that thinks the vanilla js example is actually easier to read and work with? - "The setup is noise and boilerplate heavy." Actually the signals example looks just as noisy and boilerplate heavy to me. And it introduces new boilerplate concepts which are hard for beginners to understand. - "If the counter changes but parity does not (e.g. counter goes from 2 to 4), then we do unnecessary computation…
I think there is room for improvement in how we explain this. The problems aren’t really visible in this small sample and comes up more for bigger things. PRs welcome.