// the find
mobxjs/mobx
Simple, scalable state management.
MobX is a signal-based reactive state management library for JavaScript/TypeScript that tracks observable state at runtime and automatically re-renders only the components that depend on what changed. It's been around since ~2015, is used in production at Canva, Coinbase, and similar scale, and offers a fundamentally different mental model than Redux: mutate state directly, let the reactivity graph figure out the rest. Best fit for teams who find Redux's boilerplate exhausting but want something more structured than raw React context.
The dependency tracking is genuinely zero-configuration — `makeAutoObservable` infers observables, actions, and computed values from your class shape without any annotation ceremony. Computed values are memoized and lazy by default, so you get derived state that only recalculates when its inputs change, not on every render. The `observer()` wrapper integrates with React's concurrent mode and avoids the selector-writing overhead of Zustand/Redux; components subscribe to exactly the fields they read, nothing more. The monorepo ships `eslint-plugin-mobx` with rules that catch common mistakes (forgetting `observer`, unconditional `makeObservable` calls) at author time rather than runtime.
The magic cuts both ways — when a component stops re-rendering and you don't know why, diagnosing it requires understanding the dependency graph, which isn't visible without reaching for the devtools or `trace()`. The `strict mode` story is confusing: you can opt into requiring all mutations to go through actions, but it's off by default, so new developers mutate state outside actions and create subtle async bugs before they realize what's happening. Class-based stores are the idiomatic pattern and that shows its age — the hooks ecosystem and functional components fit awkwardly with class instances, and `useLocalObservable` is a leaky abstraction that trips people up when they try to destructure observables. TypeScript support is solid but decorator support still depends on which decorator proposal your transpiler targets, and the migration docs between MobX 4/5/6 are genuinely painful if you're on a legacy codebase.