Events(developer.mozilla.org)
developer.mozilla.org
Events
https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Scripting/Events
24 comments
I often imagine state and events as the two impulses that drive an application. I like React a lot, but a common pitfall is that it is 95% focused on state, and so you get odd cases where you end up trying to encode events as state.
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.
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.
Reactivity works by replaying code when its inputs have changed. Events can make this very expensive and impractical, because to properly replay event-driven code, you'd need to replay every event it's ever received.
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.
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.
A phrase that I was expecting to see is "state transition." You want to be able to specify and execute actions on particular state transitions. In your case, you want to be able to emit events from these actions.
There's a bit about effects vs events in React's own docs: https://react.dev/learn/you-might-not-need-an-effect
I tend to be sus of usePrevious. Not saying it doesn't have a place, but often times it's cleaner to just write the diffing code you want directly in the handler. For instance, say you have a text field, and if the value changes you want to autosave. I would just put that right in the onBlur - `if (e.currentTarget.value != text) { autosave(e.currentTarget.value) }`. If you want to debounce, I would debounce the method, not the value.
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.
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.
this is what reducers are for. Though reducers tend to make you end up needing to do a bunch of stuff on async event handling which can feel _pretty_ tedious. And if you don't do the tedious way, you often end up intro'ing really hard to debug issues.
Why is this so weirdly prescriptive about inline event handlers?
> 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?
> 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?
>Why is this so weirdly prescriptive about inline event handlers?
>> 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...
>> 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...
Inline handlers could execute trusted code without user input but in a way that was unintended like this button that hijacks a method of a trusted library and disguises it behind a like button:
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP...
edited: tried to fix formatting
<button
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP...
edited: tried to fix formatting
> 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”).
It is a vector for script injection, and should be disallowed with a strong CSP (no “unsafe-inline”).
Isn’t that only the case when the inline code uses untrusted user data somehow?
Inline: alert(“Hello “+userInput) is problematic.
Inline: alert(“Hello there”) isn’t, right?
Inline: alert(“Hello “+userInput) is problematic.
Inline: alert(“Hello there”) isn’t, right?
CSP is a defense in depth mechanism which can be (among other capabilities) used to preempt the capability of inline scripts. This mitigates rendering bypasses, in the event that unsafe rendering occurs. For example, imagine you have an insecure markdown renderer, where a user can manage to escape some HTML and inject it into the DOM in a comment thread of some sort. If they can do so, then they can embed JS inside that HTML and get XSS on other users. Adding a rule to disallow all inline scripts mitigates this, assuming the first layer of defense fails.
Under a properly configured CSP, allowing scripts that aren't from the same origin to inject things into the DOM is the problem.
Both of your examples are problematic.
Both of your examples are problematic.
Using Svelte and building global state classes with $state(), $effect() has really helped with managing side-effects and surgical updates without building a custom event system which has historically added unnecessary boilerplate to many of my projects with a frontend.
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.
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.
One of my favorite quotes coming out of the Svelte team with respect to runes[0]:
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.
[0] https://svelte.dev/blog/runes#Signal-boost
> 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.
[0] https://svelte.dev/blog/runes#Signal-boost
You can think of any software (or hardware) as a state that transitions to a new state when an event happens.
State0 -event0-> State1 -event1-> State2 etc.
In other words, it's all a state machine.
State0 -event0-> State1 -event1-> State2 etc.
In other words, it's all a state machine.
What the MDN documenation doesn't make clear, is the relationship between Inline Event Handlers and Event Handler Properties
<div id="DIV"><script>
<div id="DIV"><script>
DIV.onclick = (evt) => console.log(2)
DIV.addEventListener("click",()=>console.log(3))
> Event handler properties have disadvantages compared to addEventListener(). One of the most significant is that you can't add more than one listener for a single event. The following pattern doesn't work, because any subsequent attempts to set the property value will overwrite earlier ones:
That's not really a disadvantage, rather it makes it easy to change the event handler.
That's not really a disadvantage, rather it makes it easy to change the event handler.
When is it ever necessary to change event handlers?
Protip: Make your web SDK APIs EventTargets instead of creating custom event subscription models wherever practical.
I dropped all state except local state in react and replaced it with events.
Driving UI declaratively via prop changes sounds great in theory but it’s actually a nightmare. Better to use events, dramatically simplifies things.
Driving UI declaratively via prop changes sounds great in theory but it’s actually a nightmare. Better to use events, dramatically simplifies things.
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.