[brundolf]

MobX is the equivalent for the space of reactive web frameworks, and I agree it's a fantastic model. The cost is that it requires a little "magic", but the benefit is that the entire question of synchronizing state virtually disappears, leaving you to focus on modeling and controlling state (which are still nontrivial)

[trulyme]

No. Just no. You simply can't use "MobX" and "fantastic" in the same sentence.

There are just so many problems with MobX. For example reactions - ever tried figuring out why some value changes in a bigger app? Not to mention abysmal tooling (compared to Redux DevTools). But the biggest problem is that everything is... sprinkled with magic. Just give me Redux(-toolkit), thank you very much, I can understand these much more deeply. /rant

If I sound confrontational, sorry about that... I just had the misfortune of inheriting a MobX app. Magic indeed.

[DecoPerson]

My experience with MobX has been the opposite.

I introduced MobX (along with HTML5 UI, React, TypeScript, etc) to a large team and it went swimmingly. Debugging/stepping-through was no more tedious than regular Chrome DevTools debugging.

I recommend using MobX’s strictest setting (where changing reactive objects can only occur in named actions), and restricting reactivity to a monolithic “model” (mdl) object and its children.

It really does make writing fast, correct & good UI a breeze, in my experience.

[brundolf]

The thing about MobX's magic is that it is small, and simple, and easy to learn predictably. Once you understand it, it's only "magic" in the sense that it's automatic, not in the sense that it's inscrutable or unpredictable.

[Sophistifunk]

I've had the exact same experience, only the problem was redux and the solution was mobx. Anecdotes are not universal truth.