MobX takes a fundamentally different approach from Redux: instead of explicit actions and immutable updates, it uses transparent reactivity — you mutate observable state directly, and MobX automatically tracks dependencies and updates whatever depends on it (similar to Vue's reactivity or Signals).
{ makeAutoObservable } ;
{ observer } ;
{
count = ;
() { (); }
() { .++; }
() { . * ; }
}
store = ();
= ( (
));
You mutate state directly (this.count++), and MobX automatically re-renders only the observer components that read count. No reducers, actions, dispatch, or manual immutability.
Redux MobX
Updates immutable (return new state) mutable (change in place)
Mechanism explicit actions + reducers transparent reactive tracking
Data flow strict one-way, predictable automatic dependency reactions
Boilerplate more less
Derived values selectors (manual) computed (automatic, cached)
Mental model functional / explicit OOP / reactive / implicit
MobX wraps observables in proxies. When an observer component renders, MobX records
which observables it READ. When any of those change, MobX re-runs exactly that
component — fine-grained, automatic, no selectors needed.
This is the same track-on-read/trigger-on-write idea behind Vue's reactivity and Signals.
MobX pros: less boilerplate, automatic reactivity, easy derived values, OOP-friendly
MobX cons: "magic" can be less explicit/traceable than Redux's logged actions;
mutation-based flow is harder to time-travel debug than pure reducers
MobX represents the reactive/mutable school of state management — the opposite of Redux's explicit/immutable approach.
Understanding the contrast clarifies a key design axis: explicit-and-predictable (Redux: trace every action, but more boilerplate) vs. automatic-and-concise (MobX: mutate freely, less code, but less explicit).
The same reactive principle underlies Vue and Signals, so grasping MobX illuminates a whole family of state tools and helps you choose between predictability and ergonomics for a given project.