When building React applications, managing state across components can become challenging. While solutions like Context API, Redux, or Zustand are ...
For further actions, you may consider blocking this person and/or reporting abuse
Just an FYI, the event paradigm in react becomes highly problematic. It's just as bad as combining angular and react in a real world application. They know nothing of each other and you end up with the worst of both worlds. Architecture is the solution, but this solution becomes an uneconomical problem, as it usually does when you bypass the original intent and integrations your main framework vendor intended you to use.
That being said, it is a good implementation since it's isolated, I usually see all this inside the main 800 line react function, lol. Really though, they should be converted to state hooks and lifted if appropriate. Remember react has a virtual dom, not the browser dom... your editing the browser dom there I think without telling react... so the react state becomes invalid. Worst, human devs end up having no idea what's happening. I love events... but if you use em, definitely you shouldn't be using react... they work very well with pure js, very bad with react, thee hath been warned... one need not two systems of managing events.
New devs should pay attention to this ^ comment
True, the first thing I learned when I was React noob developer is always to keep state and VDOM consistent with React itself and don't try to control elements without React data flow.
I used this approach years ago on an old class based React app, here's a few things I learned:
Well said, @ansa70! All these points are very important. I think I covered each one in my implementation. Did you notice if I forgot something?
Maybe you'd want to take a look at useSyncExternalStore
Nice, thanks for the recommendation, I'm gonna take a look!
This works for smaller/hobby apps but it's much easier to scale if you just use zustand as the single source of truth.
You may need to add some complexity if you want to handle multiple same-name events in the same component.
Interesting, even though I knew browser custom events, I never considered the potential to use them to handle state in React apps, it's the kind of knowledge that is worth having in my pocket
Absolutely, Jean! It's very useful and you can customize whatever you want. Glad this helped you, thanks for reading!
Dude, do not trick people to fall in this trap... React is not Node. Event driven React is one of the most React ani-pattern things to implement and it's hell to debug in a bigger app. I've been working on such app and believe me, I'm not going there again.
Nice of you to put effort in this article but I highly recommend you to research very good what you want to write about before posting it.
I don't see any added benefits, only drawbacks. @gunslingor described really well all the problems you will encounter with this approach.
You are basically re-implementing React's internals.
If you want to go with this approach you shouldn't be using React.
Good article. Custom events are a powerful mechanism that I use all the time. It's sad to see React fanboys refer to this as an anti-pattern. You're missing out guys. There's plenty other DOM concepts that React components don't support, like simple properties and methods. This shouldn't be considered a feature. It's a limitation. Don't believe the React hype that it's for your own good. Bad devs will make a mess of anything. Even React.
Isn't this what a store is for?