MobX

MobX is a battle-tested reactive state management library that makes application state observable and automatically tracks which values a computation reads, so derivations (computed values, autorun, reactions, and React observer components) update themselves only when the values they actually depend on change. There is no manual subscription list, selector, or memoization boundary to maintain by hand.

Originally built for React but usable with any UI layer or none at all, MobX ships as a zero-runtime-dependency TypeScript library with companion packages (mobx-react, mobx-react-lite) providing React bindings. It supports both a functional API (observable(), computed(), action()) and a class-based API via decorators or makeObservable()/makeAutoObservable(), and has remained actively maintained and API-stable across years of production use.

What You Get

• The core mobx package (observable, computed, action, autorun, reaction, when, makeObservable, makeAutoObservable) with zero runtime dependencies
• React bindings via the companion mobx-react and mobx-react-lite packages, including the observer() wrapper for automatic component re-rendering
• A codemod package (mobx-undecorate) for migrating decorator-based code to the plain makeObservable API
• An eslint-plugin-mobx package that enforces MobX-specific best practices, such as correct action wrapping and avoiding unintentional derivation side effects
• CJS, ESM, and UMD builds plus hand-written TypeScript type definitions for direct browser, bundler, or Node usage

Common Use Cases

• Managing shared application state in a React or React Native app without a Redux-style reducer/selector layer
• Building deeply nested, frequently mutated UI state (spreadsheets, editors, admin dashboards) where fine-grained updates matter for performance
• Wrapping async workflows (data fetching, polling, cancellable operations) in flow() so observable state stays consistent across await boundaries
• Incrementally introducing reactivity into an existing class-based or imperative codebase via makeObservable() rather than rewriting state management wholesale

Under The Hood

Architecture MobX’s core algorithm lives in packages/mobx/src/core/ (atom.ts, derivation.ts, computedvalue.ts, reaction.ts, observable.ts, globalstate.ts). The central abstraction is the derivation (autorun/reaction/computed), which tracks which observables it read during its last run via an explicit dependency-state machine (NOT_TRACKING_/UP_TO_DATE_/POSSIBLY_STALE_/STALE_ in core/derivation.ts), letting MobX skip recomputation unless a shallow dependency actually changed value rather than merely because some parent changed. Observable state (types/observablearray.ts, observablemap.ts, observableobject.ts, observableset.ts, observablevalue.ts) wraps native JS structures behind Proxies or getter/setter pairs that call the same reportObserved/propagateChanged primitives atoms use, so any read inside a tracked function is registered as a dependency automatically. Actions (core/action.ts) batch mutations into a single transaction so reactions run once per logical update instead of once per field write. The public surface in api/ (observable.ts, computed.ts, autorun.ts, reaction.ts, action.ts, makeObservable.ts, flow.ts) is a thin layer of factory functions and decorators wiring together these core primitives, re-exported from a curated internal barrel (internal.ts) that also verifies globals like Map/Set/Symbol exist before the module initializes.

Tech Stack The package is written entirely in TypeScript and has zero runtime dependencies (packages/mobx/package.json declares an empty dependencies object), and it ships multiple build targets — CJS (dist/index.js), ESM (dist/mobx.esm.js), and a UMD bundle for direct browser use — plus hand-written .d.ts type definitions. It is built inside an npm-workspaces monorepo (the root package.json defines mobx, mobx-react, mobx-react-lite, mobx-undecorate, and eslint-plugin-mobx as sibling packages), using Jest 30 with ts-jest for tests, ESLint plus typescript-eslint and Prettier for style, Changesets for release/versioning, and Husky with lint-staged for pre-commit checks.

Code Quality Test coverage is substantial: packages/mobx/tests/base/ contains dozens of spec files covering the public surface (autorun.js, action.js, extendObservable.js, decorate.js, flow.js, strict-mode.js, spy.js, extras.js, and more), with dedicated suites for stage-3 decorators (tests/decorators_20223/) and a perf/ directory for microbenchmarks, run via jest/jest —coverage and tracked with a Coveralls badge in the README. Internal code uses an explicit naming convention — a trailing underscore on internal-only fields such as dependenciesState_ and observing_ — to visually separate private implementation state from the public API, and core files like derivation.ts and observable.ts are heavily commented, explaining the reasoning behind optimizations (for example, why the POSSIBLY_STALE state exists) rather than leaving the algorithm undocumented.

API Design MobX exposes a small number of composable primitives — observable, action, computed, autorun/reaction/when — that work as plain functions, ES decorators, or via makeObservable/makeAutoObservable for existing classes, so consumers can use class fields, plain object literals, or a functional style without changing the underlying reactivity model. React bindings are deliberately factored into separate mobx-react/mobx-react-lite packages rather than baked into core, keeping mobx itself framework-agnostic. Getting started requires very little boilerplate: makeAutoObservable(state) plus wrapping a render function in observer() is enough to get fully fine-grained reactivity, and the extensive documentation site (mobx.js.org) plus an interactive introductory tutorial keep the learning curve manageable.