Signal 简介

大家好，这里是大家的林语冰。本期《前端翻译计划》共享的是 Preact 的一篇官方博客。

地球人都知道，一大坨 JS 框架都已经引入了 Signal（信号）筑基的响应式原理：

• Vue Ref
• Solid Signal
• Angular Signal
• Preact Signal

Signal 是一种表达状态的方式，它能确保无论 App 变得多复杂，它们都能保持高性能。Signal 基于响应式原理，并提供出色的开发者人体工程学设计，且具有针对虚拟 DOM 优化的独特实现。

免责声明

本文属于是语冰的直男翻译了属于是，略有删改，仅供粉丝参考，英文原味版请临幸 Introducing Signals。

从本质上讲，Signal 是一个具有 .value 属性并保存某些值的对象。当 Signal 的值变化时，从组件内访问 Signal 的 value 属性会自动更新该组件。

除了简单易写之外，这还可以确保无论您的 App 有多少组件，状态更新都能保持高性能。默认情况下，Signal 性能惊人，它会在幕后自动为您优化更新。

import { signal, computed } from '@preact/signals'

const count = signal(0)
const double = computed(() => count.value * 2)

function Counter() {
  return (
    <button onClick={() => count.value++}>
      {count} x 2 = {double}
    </button>
  )
}

与 Hook 不同，Signal 可以在组件内外使用。Signal 还可以与 Hook 和类组件“梦幻联动”，因此您可以按照自己的节奏引入它们，并随时运用现有的知识。在若干组件中小试牛刀，并随着时间的推移渐进式采用它们。

顺便一提，我们始终坚持为您提供尽可能小的库的初衷。在 Preact 中使用 Signal 仅会增加 1.6kB 的打包体积。

Signal 可以解决哪些问题？

在过去的几年里，我们开发了各种各样的 App 和团队，从小型初创公司到拥有数百名开发者同时交付的大型企业。在此期间，核心团队中的每个人都注意到 App 状态管理方式反复出现的问题。

人们已经创建了某些出色的技术方案来解决这些问题，但即使是最好的解决方案，也仍然需要手动集成到框架中。因此，我们看到开发者在采用这些解决方案时犹豫不决，它们反而更喜欢诉诸框架提供的状态原语构建。

我们将 Signal 打造成一个引人注目的解决方案，它将最佳性能和开发者人体工程学与无缝框架集成相结合。

全局状态混乱

App 状态起初通常短小精悍，可能是若干简单的 useState 钩子。随着 App 的增长，更多的组件需要访问同一状态，该状态最终会提升到一个公共的祖先组件。这种模式会重复多次，直到大多数状态最终接近组件树的根组件。

这种情况对传统的虚拟 DOM 筑基的框架提出了挑战，该框架必须更新受状态失效影响的整个树。本质上，渲染性能是该树中组件数量的函数。我们可以通过使用 memo 或 useMemo 对组件树的部分内容记忆化来解决这个问题，以便框架接收相同的对象。当没有任何变化时，这可以让框架跳过渲染树的某些部分。

虽然理论很合理，但是现实更混乱。实际上，随着代码库的增长，很难确定在哪优化。通常，即使是善意的记忆化也会因不稳定的依赖值而变得无效。由于 Hook 没有可以分析的显式依赖关系树，因此工具无法帮助开发者诊断依赖关系不稳定的原因。

Context 混乱

团队实现状态共享的另一个常见解决方法是将状态置于 context 中。这允许通过潜在地跳过 context provider 和 consumer 之间的组件的渲染来短路渲染。但有一个问题：只能更新传递给 context provider 的值，并且只能作为一个整体进行更新。更新通过 context 公开的对象属性不会更新该 context consumer —— 粒度更新是不可能事件。处理此问题的可用选项是将状态拆分为多个 context，或者在 context 对象的任何属性发生更改时，通过克隆 context 对象来使 context 对象失效。

起初，将值转移到 context 中似乎值得权衡，但仅仅为了共享值而增加组件树大小的缺点最终会成为一个问题。业务逻辑最终不可避免地取决于多个 context 值，这可能迫使它在树中的特定位置实现。在树中间添加订阅 context 的组件成本很高，因为它减少了更新 context 时可以跳过的组件数量。此外，订阅者下面的任何组件现在都必须再次渲染。解决这个问题的唯一方法是大量使用记忆化，这让我们回到了记忆化固有的问题。

寻找更好的状态管理方法

我们回到绘图板寻找下一代状态原语。我们想要创造某些能够同时解决当前解决方案中的问题的东东。手动框架集成、过度依赖记忆、上下文使用欠佳以及缺乏程序可观察性都让人感觉倒退。

开发者需要“选用”这些策略来提高性能。如果我们可以扭转这种情况并提供一个默认速度很快的系统，使最佳情况下的性能成为您必须努力选择退出的东西，那该怎么办？

我们对这些问题的答案是信号。这是一个默认速度很快的系统，不需要在整个 App 中实现记忆化或技巧。Signal 提供了细粒度状态更新的好处，无论该状态是全局的、通过 props 或上下文传递的，还是组件本地的。

向未来发出信号

Signal 背后的主要思想是，我们不直接通过组件树传递值，而是传递包含该值的 Signal 对象（类似于 ref）。当 Signal 的值变化时，Signal 本身保持不变。因此，Signal 可以更新，而无需重新渲染它们所经过的组件，因为组件看到的是 Signal 而不是它的值。这让我们可以跳过渲染组件的所有昂贵工作，并立即跳转到树中实际访问 Signal 值的特定组件。

我们正在利用这样一个事实：App 的状态图通常比其组件树浅得多。这会带来更快的渲染速度，因为与组件树相比，更新状态图所需的工作要少得多。在浏览器中测量时，这种差异最为明显 —— 下面的屏幕截图显示了对同一 App 测量两次的 DevTools Profiler 跟踪：一次使用 Hook 作为状态原语，第二次使用 Signal：

Signal 版本远远优于任何传统的虚拟 DOM 筑基的框架的更新机制。在我们测试过的某些 App 中，Signal 速度快得多，以至于很难在火焰图中找到它们。

Signal 扭转了性能调高：Signal 默认很快，而不是通过记忆化或选择器选择性能。对于 Signal，性能可以选择弃用（通过不使用 Signal）。

为了达到这种性能水平，Signal 是基于以下关键原则构建的：

• 默认是惰性的：仅观察和更新当前在某处使用的 Signal —— 断开连接的 Signal 不会影响性能。
• 最佳更新：如果 Signal 的值未更改，则使用该 Signal 值的组件和作用（effect）将不会更新，即使 Signal 的依赖性已更改。
• 最佳依赖项跟踪：框架跟踪哪些 Signal 由您决定 —— 没有像 Hook 那样的依赖数组。
• 直接访问：访问组件中 Signal 的值会自动订阅更新，无需选择器或 Hook。

将 Signal 引入 Preact

确定了正确的状态原语后，我们开始将其连接到 Preact。我们始终喜欢 Hook 的一点是，Hook 可以直接在组件内部使用。与第三方状态管理解决方案相比，这是一个符合人体工程学的优势，第三方状态管理解决方案通常依赖于“选择器”函数或将组件包装在特殊函数中来订阅状态更新。

// 选择器筑基的订阅 :(
function Counter() {
  const value = useSelector(state => state.count)
  // ...
}

// 基于订阅的包装函数 :(
const counterState = new Counter()

const Counter = observe(props => {
  const value = counterState.count
  // ...
})

这两种方法都令我们满意。选择器方法需要将所有状态访问包装在选择器中，这对于复杂或嵌套状态来说变得乏味。将组件包装在函数中的方法需要手动包装组件，这会带来许多问题，比如缺少组件名称和静态属性。

在过去的几年里，我们有机会与许多开发者密切合作。一个常见的难题，特别是对于那些刚接触 (p)react 的人来说，是选择器和包装器之类的概念是额外的范式，必须先学习这些范式，然后才能对每个状态管理解决方案感到富有成效。

理想情况下，我们不需要了解选择器或包装函数，并且可以直接在组件内访问状态：

// 请想象这是某个全局状态，且整个 App 需要访问它：
let count = 0

function Counter() {
  return <button onClick={() => count++}>value: {count}</button>
}

代码一目了然，浅显易懂，但不幸的是，它不起作用。单击按钮时组件不会更新，因为无法知道 count 已更改。

但我们无法摆脱这种场景。我们可以做些什么来使如此清晰的模型变成现实？我们开始使用 Preact 的可插入渲染器对各种想法和实现进行原型设计。这需要时间，但我们最终找到了实现这一目标的方法：

// 请想象这是某个全局状态，且整个 App 需要访问它：
const count = signal(0)

function Counter() {
  return <button onClick={() => count.value++}>Value: {count.value}</button>
}

没有选择器，没有包装函数，什么都没有。访问 Signal 的值足以让组件知道，当该 Signal 的值变化时，它需要更新。在若干 App 中测试了原型后，很明显我们正在做某些事情。以这种方式编写代码感觉很直观，不需要任何“心理体操”就能让事情保持最佳状态。

我们还能走得更快吗？

我们本可以停在这里并按原样发布 Signal，但这就是 Preact 团队：我们需要看看我们可以将 Preact 集成推进到什么程度。在上面的 Counter 示例中，count 的值仅用于显示文本，这实际上不需要重新渲染整个组件。如果我们只重新渲染文本，而不是在 Signal 的值变化时自动重新渲染组件，那会怎样？更好的是，如果我们完全绕过虚拟 DOM 并直接在 DOM 中更新文本又会怎样？

const count = signal(0);

// 取而代之：
<p>Value: {count.value}</p>

// 我们可以直接将 Signal 传递给 JSX：
<p>Value: {count}</p>

// 或者甚至将它们用作 DOM 属性传递：
<input value={count} onInput={...} />

是的，我们也干了。您可以将 Signal 直接传递到 JSX 中通常使用字符串的任何位置。Signal 的值将渲染为文本，并且当 Signal 变化时，它会自动更新。这也适用于 props。

您现在收看的是《前端翻译计划》，学废了的小伙伴可以订阅此专栏合集，我们每天佛系投稿，欢迎持续关注前端生态。谢谢大家的点赞，掰掰~

原文链接：https://juejin.cn/post/7313822358456287258 作者：人猫神话