3 ms·
The issue with using eventemitter for state coordination is that when the UI grows into complexity you run into race conditions where some component isn't showi
by lf-non 5y ago
The issue with using eventemitter for state coordination is that when the UI grows into complexity you run into race conditions where some component isn't showing the right data because it got mounted too late or something somewhere up the hierarchy changed a key and the component got recreated and its state got lost.
I guess as long as long as the component hierarchy fits in your head, it is likely straightforward to reason about all the event interactions.
The lifted state model ala redux (and similar alternatives) doesn't suffer from this problem.
I personally prefer effector [1] these days because it combines the convenience of event emitter with multiple stores and you usually find yourself thinking much less about what changed the store causing my component to rerender much less often.
[1] https://effector.dev/ https://effector.dev/
- leetrout 5y agoHave you ever used mobx?
- lf-non 5y agoYes, I love mobx and have used it in a few projects. It is a quite a bit larger and I can live without the transparent reactivity. YMMV.
- brundolf 5y agoSeconding MobX; it elegantly solves most of the issues with events (both maintainability and performance) while also being more ergonomic/concise. I can't praise it enough.
- andrewstuart 5y agoSo far eventemitter has resulted only in simplicity and no race conditions. Perhaps that's because it's a small application.