MobX does not get enough love and has been around for a while
Vuex has a nice pattern with plugins and modules.
Mobx stands on its own outside of react. I understand many people don’t consider redux outside of react and don’t talk about one without the other. As other comments mentions the mobx state tree is more a drop in replacement for redux. I am unfamiliar with the render method changes you reference- do you have more info or a link?
Agreed. But the mess they make in MobX is in my experience much more difficult to clean up.
What I meant with render method changes is that mobx tracks access to state during a call to render (which means that anything that might influence rendering, must be accessed inside render). It seems like it's not a big deal, but it can lead to surprising bugs if one is not careful. Redux otoh uses props to pass data to render, which is much more explicit and allows regular react dev tools to be used.
I might have some details wrong - I met MobX a year ago with two legacy apps and it was a hell to maintain. Still is actually, I'm just not that involved in these projects anymore. It's magic, and not in a good way. For new projects we use Redux Toolkit, which strikes a nice balance between verbosity and being explicit.
And Redux is just one big global state
> it is _magic_ - I would have trouble rewriting it from the docs, would you be able to do it?
I accidentally wrote a (bad) version of MobX's core mechanism before I learned about it. At its heart it just uses object Proxies to intercept getters and setters; the former to find out where something is used, the latter to find out when it changes.
It can feel a bit magical sometimes, but the magic isn't hard to understand, almost always just works, and when it doesn't do what you want it usually causes a performance impact, not breakage.
> Note that it also changes the way React render method works.
I don't know what you mean. Aside from "tracking" which observables get accessed within it, all it does is decide when to trigger updates.
E.g. https://sveltematerialui.com/
The Next.js equivalent for SSR is Sapper: https://sapper.svelte.dev/
Note the creator of Svelte is the same guy who created the Rollup bundler so pretty much everything comes with dual configs for both Rollup and Webpack.
https://svelte.dev/examples#writable-stores
What's up with that? A strange semi-singleton where you need to use writable(0)? Also strange that subscribe return unsubscribe. Doesn't seem very intuitive.
I'm not sure who downvotes me, people who successfully used them in production or who dont and don't know they are in for the ride, but for me this is an insanity and I won't touch mobx even with a six feet pole.
People would get too clever and abstract way too much. I don’t see the same with Vuex and MobX but I can understand why you feel that way based on this reply.
The concept of having a centralized state / store with complex apps is impossible to ignore IMO (even if you just have plain objects holding them). At that point sprinkling in a pattern to standardize access isn’t that much overhead.