4 ms·
MobX and chill. No compiler necessary. If React created better extension points for pluggable reactivity we wouldn't even need observer() wrappers. This is al
by Rapzid 3y ago
MobX and chill.
No compiler necessary.
If React created better extension points for pluggable reactivity we wouldn't even need observer() wrappers. This is all getting kinda bonkers.
- sesm 3y agoMobX re-introduces all push-reactivity problems that React removes.
- machiaweliczny 3y agoIt can do it but not necessarily. I think in strict mode only actions can modify state and if you use reactivity only for rendering then it great
- Rapzid 3y agoCan you elaborate on this? React's in-built reactivity system via props and context are certainly push. I'm not even aware of a pull-based reactivity system.
- sesm 3y agoReact developers wrote about this here: https://legacy.reactjs.org/docs/design-principles.html#scheduling https://legacy.reactjs.org/docs/design-principles.html#sched... Let me try to explain this differently: A typical reactive framework architecture (RX, Knockout, etc) looks like this Events -> Observables -> Computed values -> Subscriptions -> DOM updates It aims to provide a targeted DOM update in response to event as soon as possible, but it has several major disadvantages: 1. Batching and prioritizing capabilities either don't exist, or are limited and generic, in particular by default they are not tied to UI structure, because the framework itself doesn't want to be aware of UI structure, it just wants the framework user to provide event sources and write update targets manually. 2. Computed values are computed if corresponding subscriptions are active. In contrast, React hides state propagation logic inside the component tree, so the computation happens only when components are actually rendered. Issue 1 is not relevant for MobX-React case, because React is doing UI update batching and prioritisation. But issue 2 is very real, especially when using React Router. I had multiple cases where Computed values were computed at unexpected point in time and used observable values that were not initialised, while corresponding React components were not even visible on the screen.
- CornCobs 3y ago+1 for mobX. Dead straightforward, does one thing and does it well. Only worry is that it increasingly feels like an outsider in React. I'm working on an app that uses React, web components and mobX, and upgrading to React 18's concurrent rendering breaks stuff, and I'm not sure which of my relatively niche technologies (mobX or WC or maybe the interaction of the 2?) causes it. Preact has been looking increasingly attractive as a library that does its own thing and nothing more. Anyone knows if preact signals are basically a drop in replacement for mobX?
- Rapzid 3y agoYeah, it's bizarre how it's essentially been doing what all these newish(past 4 years or so) state management libraries and frameworks are rediscovering the entire time and yet.. It gets snubbed. Not even mentioned as a state management library by Tanstack Query. Always left out of the conversation. And yet, AFAICT, it's actually pretty quietly, and heavily used in the "app" space by a bunch of very large companies.
- satvikpendem 3y agoMobX is how you get spaghetti code and state changes everywhere. That is why we (our company) moved away from the observer pattern that MobX and RxJS use.
- deleted 3y ago[deleted]
- Rapzid 3y agoWhat did you move to? I've seen plenty of spaghetti code with just about every other React state management (reactivity) approach. The benefit of MobX to me is I can write a more traditional "domain" layer and wire the view in on top of it keeping a good separation between business/domain logic and UI concerns.