MobX doesn't get enough hate either. Inexperienced devs will put everything in the global state and end up with a soup. And, as opposed to Redux, it is _magic_ - I would have trouble rewriting it from the docs, would you be able to do it? Note that it also changes the way React render method works. All in all - no thank you.

Sloppy developers are sloppy in redux as well.

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?

> Sloppy developers are sloppy in redux as well.

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.

> Inexperienced devs will put everything in the global state and end up with a soup.

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.

I love love love MobX. It lets me design my data flow however I want - local or global, functional or imperative, and everything in-between - while basically forgetting about pub/sub entirely until it comes time to do spot optimizations. It's removed an entire layer of mental overhead, without contorting the entire app into a complex and boilerplate-y new paradigm.

I found the philosophy communicated by mobx-state-tree to be a lot clearer than redux (particularly stuff around patches, snapshots and async flows): https://mobx-state-tree.js.org/intro/philosophy

Check out Svelte. Essentially reactivity baked into the compiler so you don't have to use observables everywhere.

One of the main reasons I'm using Redux is because of the global store. If I understand the docs correctly this is how you do it in Svelte:

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.

Second time it’s been mentioned in as many days. Are you actively using it?

Yes it is pretty straightforward though the project is still growing and suffering from the usual growing pains. Think docs that has plenty of room for improvement, insufficient example projects and components. On the up side the team responds quickly, the concepts are ridiculously simple compared to Redux and there's a burgeoning community around it.

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.

IDK, it's good to have competition but I could never get warm with mobx, undo is not baked it, more magic, similar learn curve but less real understanding at the end. Then, the biggest bummer, you have also mobx state tree which is too much fragmentation within mobx.

Friends don't let friends use observables

Could you elaborate on this?

I saw enough large scale knockout projects to see how quickly observable based code fold down into a disjoined incoherent mess. At some point it's virtually impossible to debug or support it.

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.

I've been using MobX on a quite large and complex React app for a few years now and I have no regrets. The key, as in all programming, is to make your (observable) state as small as possible. You shouldn't have observables that are derived from other observables; you should have computed values. You should use reactions sparingly and almost never use them to mutate other observables. Etc. MobX lets you treat state as state and then get all the benefits of memoization and reactivity that you want, for free. It only gets hairy when your state itself gets needlessly hairy.

I've been burned by observables in a large scale knockout project too. Definitely left my weary of observables for UI development in general.

I was not a fan of knockout AT ALL. But here we are.

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.

What do you use instead?