31–40 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?
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?
Did you read the document? They have an example there, which is quite similar to yours, and explain what is the problem.
Earlier quoted context omitted.
Did you read the document? They have an example there, which is quite similar to yours, and explain what is the problem.
No, they don't. In fact, if you search "event" in the proposal you get exactly one result, the prefix of "eventually". This is a serious shortcoming of the proposal that should be addressed.
Promises are a nice success story, but without async/await it wasn't really necessary to standardize > The current draft is based on design input from the authors/maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more… Would be interested what existing library authors think of this proposal. Interesting that React is not in that list Signals are a bit like c…
> “Interesting that React is not in that list” Signals are not a part of the core React API, unlike Preact. My vague gut feeling is that signals are too much like a generalized useEffect() and would only introduce further confusion into React by muddling what happens during the render cycle. For better and worse, React takes a different tack to updates than signals do. But maybe I’m wrong about their applicability.
Earlier quoted context omitted.
Did you read the document? They have an example there, which is quite similar to yours, and explain what is the problem.
No, they don't. In fact, if you search "event" in the proposal you get exactly one result, the prefix of "eventually". This is a serious shortcoming of the proposal that should be addressed.
Earlier quoted context omitted.
No, they don't. In fact, if you search "event" in the proposal you get exactly one result, the prefix of "eventually". This is a serious shortcoming of the proposal that should be addressed.
I think the comment you're replying to is referring to the pub/sub sections of the proposal. They don't explicitly mention events, but events are a subset of the publish/subscribe pattern.
The only "benefit" signals as proposed here give you is less control over the exact dispatch pattern of the graph, for instance things like debouncing, throttling, batching, etc etc etc. Aka all the things you absolutely must have control over if you want to make something resembling a high performance application.
Earlier quoted context omitted.
Did you read the document? They have an example there, which is quite similar to yours, and explain what is the problem.
No, they don't. In fact, if you search "event" in the proposal you get exactly one result, the prefix of "eventually". This is a serious shortcoming of the proposal that should be addressed.
- They introduce what is effectively a black-box system
- The new system is expected to handle all application state
- They try to push it for frontend folks while also remarking that it would be useful for build systems
This has the same red flags the xz saga had.
Have we learnt nothing.
Lots of ”users” here vouching for the pattern and hoping it gets adopted. I bet this gets some nice damage control replies because there’s social engineering going on here right now and most seem to not be aware of it.
We keep adding things to the language, and never subtract anything, which means learning it as a language is getting harder and harder.
Earlier quoted context omitted.
No, they don't. In fact, if you search "event" in the proposal you get exactly one result, the prefix of "eventually". This is a serious shortcoming of the proposal that should be addressed.
Oh, come on. They do have an example of architecture, not literal example of events. It doesn’t matter what trivial implementation of Observer pattern you choose.