备受 Vue、Angular 和 React 青睐的 Signals 演进史

图5: JavaScript备受 Vue、Angular 和 React 青睐的 Signals 演进史

最近，在前端领域，围绕着“Signals”这个词，有一些热烈的讨论。不管是Preact还是Angular，似乎都在讨论该话题。

但它们并不是什么新东西。如果我们将其追溯到上个世纪 60 年代的研究，那么这就更算不上新鲜的事物了。它的基础采用了与第一个电子表格和硬件描述语言（如 Verilog 和 VHDL）相同的模型。

即便是在 JavaScript 中，从声明式 JavaScript 框架诞生开始，我们就拥有这种理念了。随着时间的推移，它们有了不同的名字，并且在这些年里不断流行了起来。现在，它又重新出现了，这是一个很好的时机，我们可以对它是什么以及为何需要它进行更多的介绍。

免责声明：我是 SolidJS 的作者。本文从我的角度介绍了演进的过程。尽管文中没有提及，但是Elm Signals、Ember的计算属性和Meteor都是很值得称道的。

如果你还不清楚 Signals 是什么以及它是如何运行的，请参阅我的这篇对细粒度反应性（Fine-Grained Reactivity）的介绍。

起初的蛮荒时代

有时候，我们会惊讶地发现，很多参与者在完全相同的时间形成了类似的方案。在声明式 JavaScript 框架的起步阶段，有三个方案在三个月内陆续发布，它们分别是Knockout.js（2010 年 7 月）、Backbone.js（2010 年 10 月）和Angular.js（2010 年 10 月）。

Angular 的脏值检查、Backbone 的模型驱动重渲染以及 Knockout 的细粒度更新，虽然它们彼此间有些差异，但是最终都成为了我们今天管理 state 和更新 DOM 的基础。

Knockout.js 对本文的主题特别重要，因为它们的细粒度更新是建立在所谓的“Signals”的基础之上的。他们最初引入了两个概念，分别为 observable（状态）和 computed（副作用），但是在接下来的几年中，他们在前端语言中引入了第三个概念 pureComputed（衍生状态）。

const count = ko.observable(0);




const doubleCount = ko.pureComputed(() => count() * 2);




// 每当doubleCount更新时，打印日志记录
ko.computed(() => console.log(doubleCount()))

狂野时代

图0: JavaScript备受 Vue、Angular 和 React 青睐的 Signals 演进史

在这个时代，服务器端开发的 MVC 和过去几年从 jQuery 中学到的模式进行了融合，形成了新的模式。其中，最常见的一个模式叫做数据绑定，Angular.js 和 Knockout.js 都具有该模式，不过实现方式略有不同。

数据绑定的概念是，state（状态）应该被关联（attached）到 view tree（视图树）的一个特定部分上。借助这种方式，能够实现的一种强大功能叫做双向绑定。所以，我们可以让状态更新 DOM，反过来，DOM 事件会自动更新状态，所有的这一切均是以一种简单的声明方式实现的。

但是，滥用这种力量最终会作茧自缚。我们构建应用的时候，对其缺乏足够深入的了解。在 Angular 中，如果不知道什么内容发生变化，就会对整个树进行脏值检查，而向上传播会导致它多次发生。在 Knockout 中，很难跟踪变化的路径，因为你会在 DOM 上走来走去，出现循环也是司空见惯的。

当React出现的时候，我们已经准备好逃离这一切了，对我个人来说，是Jing Chen的演讲，让我稳住了阵脚。

00:00 / 44:35

1.0x

2.0x
1.5x
1.25x
1.0x
0.75x
0.5x

网页全屏

全屏

00:00

自由时刻

图4: JavaScript备受 Vue、Angular 和 React 青睐的 Signals 演进史

接下来，就是对 React 的采用。有些人依然喜欢反应式模型，因为 React 对状态管理没有自己的偏好，所以完全可以将两者结合起来。

Mobservable（2015）就是这样的方案。但是，相对于与 React 的集成，它还带来了一些新的内容。它强调一致性和顺畅（glitch-free）的传播。也就是说，对于任何给定的变更，系统的每个部分仅运行一次，而且以适当的顺序同步运行。

为了实现这一点，它使用了一种推-拉（push-pull）混合的系统来替换先前方案中基于推送的反应性。变更的通知会被推送出去，但是衍生状态的执行会推迟到读取它的地方。

图2: JavaScript备受 Vue、Angular 和 React 青睐的 Signals 演进史

为了更好地理解 Mobservable 的原始方式，请参阅 Michel Westrate 的“Becoming Fully Reactive: An in Depth Explanation of Mobservable”一文。

虽然在很大程度上，这个细节会被 React 重新渲染读取变更的组件所掩盖，但是，这是使系统实现可调试和一致性的关键步骤。在接下来的几年里，随着算法的不断完善，我们会看到一种趋势，那就是更多基于拉取的语义。

征服泄露的观察者

图3: JavaScript备受 Vue、Angular 和 React 青睐的 Signals 演进史

细粒度反应性是四人组（Gang of Four）观察者模式的变种。虽然观察者模式是一个强大的同步模式，但是它也有一个典型的问题。一个 Signal 会保持对所有订阅者的强引用，所以长期存活的 Signal 会保留所有的订阅，除非进行手动处置。

这种记录方式在大量使用时会变得很复杂，尤其是在涉及嵌套的时候。在处理分支逻辑和树的时候嵌套很常见的，就像在构建 UI 视图时的那样。

有一个鲜为人知的库，叫做S.js（2013）提供了答案。S 是独立于其他大多数解决方案而开发的，它更直接地以数字电路作为模型，所有的状态变化都在时钟周期内进行。S 将其状态基元称为“Signals”。尽管它不是第一个使用该名字的，但它是我们今天使用该术语的起源。

更为重要的是，它引入了反应式所有权的概念。所有者会收集所有的子反应式作用域，并在所有者处置（disposal）自身或重新执行时，管理子反应式作用域的处置。反应式图会从一个根所有者开始，然后每个节点均作为它所拥有的后代。这个所有者模式不仅对处置过程很有用处，而且在反应式图中，建立了一种提供者/消费者（Provider/Consumer）上下文的机制。