前端技术演化史

MobX

Properties1
tags状态管理, mobx, 响应式, 可变状态, 依赖追踪

7分钟阅读

⚡ MobX

一句话定性

如果 Redux 说”状态不可变、变化要显式声明”,MobX 就反问:“为什么?我直接改值,框架自动追踪谁用了它、自动更新不就行了?” MobX 用透明的响应式(transparent reactivity),站到了 Redux 的哲学对立面——这是状态管理钟摆的另一极。

一、它是什么 & 出现的时代

MobX 是一个响应式状态管理库,由 Michel Weststrate 创建(2015 年左右,早期名为 Mobservable),与 Redux 几乎同期诞生于 2013-2018 SPA时代。

它不绑定特定框架(可用于 React、Vue 等),但在 React 社区作为 Redux 的”另一种活法”而广为人知。其思想内核是响应式编程(reactive programming)——和后来 Vue 的响应式系统、Signals 是同源的家族。

二、为什么会出现(解决上一代什么痛点)

它要解决的就是 Redux 的痛点

Redux 的可预测性是用大量样板换的(action / reducer / dispatch / 不可变展开,详见 Redux副作用)。MobX 的出发点很直接:

  • 为什么改一个值要写三个文件?
  • 为什么要手动 dispatch、手动声明”哪些组件该更新”?
  • 为什么要被迫写不可变的深层展开?

MobX 的第一性回答:这些都是机器该干的活。 你只管像写普通对象一样改数据,“谁依赖了这个数据、该更新谁”应该由框架自动算出来。

三、核心机制 & 为什么流行

透明响应式三件套

 observable(可观察状态)  ──被读取时──►  自动记录"谁在用我"
        ▲                                      │
        │ 你直接赋值修改                         ▼
   action(动作)                          reaction / 组件
        │                                (依赖变了 → 自动重跑/重渲染)
        └────────────── 自动追踪依赖图 ──────────────┘
  1. observable:把状态标成”可观察的”(makeObservable / observable)。
  2. 自动依赖追踪:当一个组件(或 computed)读取了某个 observable,MobX 就自动记下这条依赖。
  3. 自动反应:当这个 observable 被修改,MobX 精确地只更新真正用到它的那些组件——无需手动订阅、无需 selector。
class Cart { @observable items = []        // 直接可变
            get total() { return this.items.length } }  // computed 自动派生
cart.items.push(x)   // 直接改,用到 items/total 的组件自动更新

为什么流行

它的卖点是"几乎没有心智负担"

  • 样板极少:像操作普通 JS 对象一样改状态,没有 action/reducer 仪式。
  • 可变 + 自动派生:computed 值自动缓存、自动更新,符合直觉。
  • 细粒度更新:自动精确追踪依赖,天然避免不必要的重渲染(不像早期 Redux 需要手动 memo/selector 优化)。

四、带来的新问题 / 副作用

自动的代价是"不透明"

  1. 数据怎么变的难以追踪:Redux 有一本清晰的 action 日志,MobX 的变化是”四处直接赋值”触发的,调试时难以回答”这个值为什么变了”——可预测性弱。
  2. “魔法”难以推理:依赖追踪是隐式的,出问题时(比如组件没更新 / 更新过头)要理解 MobX 内部机制,黑盒感强。
  3. 可变状态违背函数式直觉:习惯了不可变数据流的人会不适应,且可变带来的别名/共享引用问题需要小心。
  4. 缺少 Redux 那种强约束:大团队里,“谁都能在任何地方直接改 state”可能重蹈双向绑定时代的混乱(二阶效应)。

五、现状 / 演化

  • MobX 仍有稳定的拥趸,尤其在复杂领域模型、面向对象风格的应用里(OOP 友好)。
  • 它的”响应式”思想是大赢家:Vue 的响应式系统、Signals(Solid/Preact/Angular)、Vue 3 的 ref/reactive 都是同一思想谱系——MobX 输了”库之争”,但赢了”范式之争”。
  • 在 React 社区,极简的 Zustand、原子化的 Jotai 等吸收了”少样板”的诉求,部分场景替代了 MobX。

六、对后续技术的影响(因果链)

        Redux 样板太多(显式/不可变的代价)
                       │
                       ▼  (反其道而行)
                 MobX(透明响应式 + 可变状态)
                       │
   ┌───────────────────┼─────────────────────────────┐
   ▼                   ▼                             ▼
 observable         自动依赖追踪                   computed 派生
   │                   │                             │
   ▼                   ▼                             ▼
 直接改值即更新     精确细粒度更新                 自动缓存
   │
   ▼
 "响应式"范式扩散 ──► [[Vue]] 响应式系统 / Signals / Vue3 ref-reactive
   │
   ▼
 与 Redux 形成 [[状态管理演进史|钟摆]]两极:
   透明响应式(MobX) ⇄ 显式不可变(Redux)

历史地位

MobX 是 Redux 的哲学对立面,二者共同定义了状态管理钟摆的两端:显式不可变(可预测但啰嗦)⇄ 透明响应式(高效但不透明)。即便 MobX 这个库不是最终赢家,它所代表的响应式自动追踪思想,已经渗透进 Vue、Signals 乃至现代框架的底层——这是它留给前端最深的遗产。

🔗 相关:状态管理演进史 | Redux | Vuex-Pinia | Zustand | React | Vue | 2013-2018 SPA时代

关系图谱

反向链接