Waterluvian
c-hendricks
There's a bit about effects vs events in React's own docs: https://react.dev/learn/you-might-not-need-an-effect
rtpg
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.
h4ch1
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.
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.