MobX: Signal-Based Reactive State Management for JavaScript

What Problem MobX Addresses and Who It Is For

MobX targets JavaScript and TypeScript developers who find the explicit dispatch-reducer-selector cycle difficult to maintain as application state grows more interconnected. The library's central premise is stated in the README: 'Anything that can be derived from the application state, should be. Automatically.' This puts the automatic tracking mechanism, not the developer's manual wiring, in charge of keeping derived values in sync.

The library fits single-page applications where many components read from the same shared state graph. Because MobX is framework-agnostic, the README notes it 'allows you to manage your application state outside of any UI framework,' which means stores can be shared across multiple rendering targets or tested in isolation without a browser environment. It is not a good fit for applications where every state change must pass through a single auditable path, since MobX distributes mutation responsibility across action methods defined anywhere in the codebase.

How Observables, Actions, and Computeds Form the Reactive Loop

MobX organizes state around three concepts. Observable state holds the values being tracked. Actions are the intended path for mutating that state. Computed values and side effects, including React component renders, re-run automatically when the observable values they read from change.

The README describes the data flow directly: 'Every event invokes an action that updates observable state. Changes in the observable state are propagated precisely to all computations and side effects that depend on the changes being made.' The word 'precisely' matters because MobX builds a dependency graph at runtime rather than comparing whole state trees. A component reading timer.secondsPassed re-renders only when that specific field changes, not when any other part of the store is updated.

The makeAutoObservable function removes manual annotation. It inspects the object passed to it and classifies plain properties as observables, methods as actions, and getter functions as computed values. Before MobX 6 introduced this function, developers annotated each property individually using the observable, action, and computed exports from the API.

Installing MobX and Connecting a React Component

The core package is available on npm as mobx. React integration uses mobx-react-lite, which provides function-component support through the observer wrapper. The mobx-react package in the workspace also adds class-component support on top of mobx-react-lite.

The README provides a complete working example that shows the full pattern: a timer store created with makeAutoObservable, a React component wrapped with observer, and the automatic re-render triggered by the observable property:

import React from "react"
import ReactDOM from "react-dom"
import { makeAutoObservable } from "mobx"
import { observer } from "mobx-react-lite"

const myTimer = makeAutoObservable({
    secondsPassed: 0,
    increase() {
        this.secondsPassed += 1
    },
    reset() {
        this.secondsPassed = 0
    }
})

const TimerView = observer(({ timer }) => (
    <button onClick={() => timer.reset()}>Seconds passed: {timer.secondsPassed}</button>
))

The observer call from mobx-react-lite subscribes the component to any observable values accessed during its render. When myTimer.increase() is called and secondsPassed changes, MobX re-renders TimerView only, not the broader component tree. No memoization or selector optimization is required.

Where MobX Creates Friction

The automatic dependency tracking that makes MobX convenient also introduces a class of silent bugs. Reading an observable value outside an observed context, such as in an asynchronous callback that fires after a component unmounts, records no dependency and produces no warning. The incorrect access looks identical to a correct one in code review, making these bugs difficult to spot.

Time-travel debugging, which Redux DevTools supports through action replay against immutable snapshots, is not part of MobX's design. The README does not document a rollback or state-replay mechanism. Teams that require a full audit trail of every state mutation will find the Redux or Zustand approach more direct for that need.

MobX uses JavaScript Proxies in modern environments. Code that serializes or clones observable objects must first unwrap them using toJS or similar utilities. Raw Proxies behave unexpectedly with some third-party libraries that rely on object identity or deep equality checks, which can produce subtle integration bugs.

MobX vs Redux: Two Different Mental Models

Redux organizes state as a single immutable object tree. Every change passes through a pure reducer function, and the previous state is always preserved. Selectors sit between the store and components, converting raw state into the shape each component needs. Every state transition is explicit and traceable, but the pattern requires writing reducers, action creators, and selectors for each domain.

MobX organizes state as mutable objects that are observed directly. There is no central store, no action creator convention, and no selector layer. Components read store properties directly, and MobX decides when to re-render them. Mutation can happen anywhere an action method is defined, which distributes responsibility differently than Redux's single entry point through reducers.

Both approaches work with React. The correct choice depends on whether the team values explicit state history and auditability, where Redux is clearer, or prefers lower boilerplate for applications with many interconnected derived values, where MobX is more direct.

The mobxjs Package Ecosystem

The repository is organized as a monorepo with five packages. packages/mobx contains the core library. packages/mobx-react-lite provides the observer function and hooks for React function components. packages/mobx-react adds class-component support on top of mobx-react-lite. packages/eslint-plugin-mobx ships ESLint rules for enforcing MobX conventions. packages/mobx-undecorate is a codemod that converts decorator-based MobX 4 and 5 code to the annotation API introduced in MobX 6.

The mobx-undecorate package is relevant for teams migrating from older codebases. Projects that still rely on the decorator syntax from MobX 4 or 5 must either run this codemod or update their TypeScript and Babel configurations to match the annotation model before upgrading to the 7.x series.

Maintenance Status and Licensing

The last push to the repository was on 2026-09-25. [email protected] was released that same day, and [email protected] followed on 2026-09-24. The project is licensed under the MIT license, which places no restrictions on commercial use, modification, or redistribution.

Major version upgrades have historically required code changes. The migration from MobX 5 to 6 required removing decorator syntax and replacing annotations with makeObservable or makeAutoObservable. The move from 6 to 7 is smaller in scope, but the release notes in the repository's .changeset/ directory are the authoritative source for breaking changes in each version. Teams upgrading from class-component-heavy codebases should verify that mobx-react, not just mobx-react-lite, is compatible with their component patterns before committing to the upgrade.

Editorial conclusion

Engineers building React apps with complex, interconnected state will find MobX's automatic dependency tracking reduces boilerplate compared to explicit selector-based approaches. Applications that require a strict, auditable state history with replay are better served by Redux's immutable model. Before upgrading an existing codebase to MobX 7, check the changeset history in the .changeset/ directory and confirm that mobx-undecorate has converted any decorator-syntax stores.

Frequently asked questions

Official sources

1. License: MIT
2. mobxjs/mobx on GitHub
3. Project website
4. README
5. Releases