posts/signals-unified-reactivity-model/

[giscus[bot]]

posts/signals-unified-reactivity-model/

把 Vue 2/3、Angular Signals、Solid.js 与 TC39 Signals Proposal 放进同一张坐标系：依赖追踪、变化传播、副作用调度。理解不同框架响应式系统背后的共同模型，而不是只记 API。

https://rowanliu.com/posts/signals-unified-reactivity-model/

[llccing]

这两个概念是响应式系统设计中非常经典的核心问题，而且它们紧密相关。我们用一个具体的数据流动过程来看看。

🧱 什么是 Naive Push（朴素推送）？

Naive Push 是一种最直接的更新策略：当一个底层状态（Signal）发生改变时，它不加思考地立刻把新值“推送”给所有依赖它的上层节点，上层节点收到后也立刻重新计算，并继续盲目地往下推送。

这种方式虽然直观，但因为缺乏全局的调度和协调，在复杂的依赖网络中会导致严重的性能问题和状态不一致，其中最著名的场景就是“菱形依赖”。

💎 什么是 Diamond Dependency（菱形依赖）？

当你的数据流拓扑结构形成了一个类似“菱形”的闭环时，就会出现这个问题。

我们来看一个经典的菱形结构：

1. 状态 A 是源状态（比如 A = 1）。
2. 计算属性 B 依赖 A（B = A * 2）。
3. 计算属性 C 也依赖 A（C = A + 1）。
4. 计算属性或副作用 D 同时依赖 B 和 C（D = B + C）。

如果此时 A 变为了 2，在 Naive Push 的机制下，会发生以下好玩的“灾难”：

1. A 改变，立刻通知 B 和 C。
2. 假设 B 动作快，先完成了更新，并立刻把新值推给了 D。
3. 此时 D 被迫开始重新计算。它读取了新的 B，但由于 C 还没来得及更新，D 只能读取到旧的 C。
4. 结果，D 在这一瞬间计算出了一个错误的中间值（在响应式中这被称为 Glitch 状态）。
5. 紧接着，慢吞吞的 C 终于更新完了，又把新值推给了 D。
6. D 再次被迫重新计算，这时候才拿到了全新的 B 和 C，得到最终正确的值。

代价：D 在一次数据变化中被执行了两次，而且中间还产生了一次错误的脏数据。

---

这就是为什么现代 Signals 系统（如 SolidJS, Vue 3, Preact Signals）都不能只用简单的 Naive Push。

[llccing]

一等 state cell

🏢 Vue 2：属性层面的响应式
在 Vue 2 中，响应式不能脱离对象单独存在。

响应式是通过 Object.defineProperty 拦截对象的某个具体属性（Key）来实现的。

局限：如果你把这个属性从对象中解构出来（例如 let { count } = this.state），这个 count 变量就会变成一个普通的数字，彻底失去响应式能力。它不是一个独立的“一等公民”。

🧪 Signals：一等 state cell
而在 Signals 系统中，状态是一个个独立的“细胞”（Cell）或“包装盒”。

你可以直接创建一个孤立的响应式单元：const count = signal(0)。

这个 count 变量本身就是一个对象，它把数据和追踪逻辑完美地包裹在了一起。

优势：你可以把 count 传给任何函数，或者从任何函数中返回它，它在传递过程中永远不会丢失响应式能力。