You’ll see this anywhere you see a usePrevious-like hook that you then use to determine if something changed and act on it (eg. I hold state that a robot is offline, but I want to do something special when a robot goes offline). This is inferring an event from state.
I’ve had luck adding an event bus as a core driver of a complex react application for events I don’t want to track as state. But it always feels that it’s a bit in conflict with the state-driven nature of the application.
When we replace an event stream with an observable variable, it's like a performance optimisation: "you can ignore all of the events which came before; here's an accumulated value which summarises the entire event stream". For example, a mouse movement event listener can often be reduced to an "is hovered" flag.
Serialising program state to plain data isn't always easy or convenient, but it's flexible enough. Reducing all events to state almost solves the problem of impure inputs to reactive functions.
Unfortunately, reactive functions usually have impure outputs, not just impure inputs. UI components might need to play a sound, write to a file, start an animation, perform an HTTP request, or notify a parent component that the "close" button has been clicked. It's really difficult to produce instantaneous side effects if you don't have instantaneous inputs to build on.
I can't see an obvious solution, but until we come up with one, reactive UI toolkits will continue to be ill-formed. For example, a React component <ClickCounter mouseButton> would be broken by default: clicks are delivered by events, so they're invisible to React, so the component will display an incorrect click count when the mouseButton prop changes.
I tend to agree with your overall assessment - your React code is not doing well if you're encoding events into state. That's why I try to avoid it! But I may be oversimplifying.
Having components bound to or using any of the $states or $derived update automatically without having to manually register event listeners, firing events, etc.
Used to dislike runes so much initially, but working a bit more deeply with them has really made me appreciate the API changes.
> Like every other framework, we’ve come to the realisation that Knockout was right all along.
>
> Svelte 5’s reactivity is powered by signals, which are essentially what Knockout was doing in 2010.
The problem is actually React hooks which has created a paradigm that inverts this and is now the most dominant model. This inversion of the model of how reactivity works is the root cause of most of the pain and complexity with React.
Context: Components that need a context value can fire an event to request it. Any other element or listener higher in the tree can handle the event and provide a value via the event object. Event are synchronous, so you can get values synchronously. The Web Components Community Group maintains an interoperable context community protocol: https://github.com/webcomponents-cg/community-protocols/blob...
Suspense: Components that have some pending some work, like awaiting data to render, can fire an event to signal that they have pending work. The event can carry a promise, and then a suspense-boundary-like component can handle the event and display a spinner until all the pending work in the tree below it is finished. Another protocol: https://github.com/webcomponents-cg/community-protocols/blob...
Error boundaries: A component can fire an ErrorEvent if it fails to render, and an error boundary component can display the error or some other user affordance.
Child-parent registration: A child component can fire an event to tell some parent that it's available. This is useful for using components as plugins. A <code-mirror> element could have children that provide language support, syntax highlight themes, etc.
Actions: Redux-like actions can be done with events instead. You can build a nice data-down, events-up system this way with very little code and very loose coupling.
Event buses: components can listen for events on a top-level node like document, and they'll receive every event of that type from every other dispatcher.
> Even in a single file, inline event handlers are not a good idea. One button is OK, but what if you had 100 buttons? You'd have to add 100 attributes to the file; it would quickly turn into a maintenance nightmare.
> You should never use the HTML event handler attributes — those are outdated, and using them is bad practice.
It’s a really good explanatory text, and then get surprisingly opinionated.
Similarly, why is an online event handler considered a security risk? I just don’t see the difference between that and using a named function?
It is a vector for script injection, and should be disallowed with a strong CSP (no “unsafe-inline”).
Inline: alert(“Hello “+userInput) is problematic.
Inline: alert(“Hello there”) isn’t, right?
Both of your examples are problematic.
<button onclick="trustedLib.confirmDeleteAccount()">Like</button>
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP...
edited: tried to fix formatting
>> Even in a single file, inline event handlers are not a good idea. One button is OK, but what if you had 100 buttons? You'd have to add 100 attributes to the file; it would quickly turn into a maintenance nightmare.
What's so weird about this? This practice, known as event delegation, has been a known Good Practice for decades. One event listener attached to a common ancestor element of 100 buttons is more memory efficient than 100 event listeners. Even jQuery, which makes it temptingly ergonomic to give 100 buttons an event listener each, prescribes the event delegation pattern in their documentation.
Edit: Sorry I just read the section; now I'm dismayed the MDN article is not prescribing/recommending event delegation. However I did find other MDN articles explaining it:
https://developer.mozilla.org/en-US/docs/Learn_web_developme...
https://developer.mozilla.org/en-US/docs/Learn_web_developme...
State0 -event0-> State1 -event1-> State2 etc.
In other words, it's all a state machine.
Driving UI declaratively via prop changes sounds great in theory but it’s actually a nightmare. Better to use events, dramatically simplifies things.
That's not really a disadvantage, rather it makes it easy to change the event handler.
<div id="DIV" onclick="console.log(1)">CLICK!</div>
<script>
DIV.onclick = (evt) => console.log(2)
DIV.addEventListener("click",()=>console.log(3))
aanthonymax•6mo ago
cranberryturkey•6mo ago