关于前端:Signal更多前端框架的选择

大家好，我卡颂。

最近，Angular、Qwik的作者 MIŠKO HEVERY 发文示意 Signal 是前端框架的将来，并思考在 Angular 中实现它。

在此之前，Vue、Solid.js、Preact、Svelte都已实现 Signal。实际上，signal 并不是一个新概念，他还有很多别名，比方：

• 响应式更新
• 细粒度更新

如果你理解过 Vue 响应式更新的实现原理，对 Signal 就不会生疏。

实际上，Signal的技术在 10 年前 Knockout 框架中就有利用。为什么这项技术正受到越来越多前端框架的青眼？

本文，让咱们一起探讨下这个话题。

欢送退出人类高质量前端交换群，带飞

signal 的实质

signal的实质，是将 对状态的援用 以及 对状态值的获取 分来到。这么说可能有点形象，让咱们先看一个 非 signal的例子。

以下是 React 中定义状态的形式：

function App() {const [state, dispatch] = useState(0);
  return <p onClick={() => dispatch(state + 1)
  }>{state}</p>
}

useState的返回值包含两局部：

• state：状态的值
• dispatch：状态的setter

能够发现，state耦合了 对状态的援用 以及 对状态值的获取 这两个含意。

再来看一个 signal 的例子。以下是同一个例子用 Solid.js 书写的样子：

function App() {const [getState, dispatch] = createSignal(0);
  return <p onClick={() => dispatch(getState() + 1)
  }>{getState()}</p>
}

createSignal的返回值包含两局部：

• getState：对状态的援用
• dispatch：状态的setter

区别就体现在 getState 上，其中：

• getState是对状态的援用
• getState()是对状态值的获取

也就是说，咱们能够不用立即获取状态的值，而是在须要的时候再获取（即在须要时再执行getState()）。

这么做有什么益处呢？如果咱们在须要的时候再获取状态的值，就能感知以后的上下文环境。

举个很毛糙的例子，在上面的代码中，组件实例（Component实例）在 render 时会将全局变量 cpnContext 指向本人：

let cpnContext = null;

class Component {render() {
    cpnContext = this;
    // ... 省略逻辑
  }
}

那么在 createSignal 返回的 getState 办法外部，能够获取全局变量 cpnContext 来感知以后处于哪个组件的渲染流程：

function createSignal() {
  // ... 省略逻辑
  function getState() {
    const curContext = cpnContext;
    // ...
  }
  function dispatch {}
  return [getState, dispatch]
}

这么做的目标是建设 状态变动 与须要更新哪个组件 之间的分割。

相比于 React，基于Signal 实现的框架会有两个劣势：

• 更好的细粒度更新性能
• 更好的DX（开发者体验）

更好的细粒度更新性能

因为 Signal 建设了状态与组件之间的分割，所以相比于 React 更有性能劣势。

比方，在我的电脑上，用 Svelte 渲染 1w 个 li，点击某个li 后扭转他的内容：

<ul>
  {#each items as item (item.id)}
      <li on:click={() => items[item.id].name = 'change!'}>{item.name}</li>
  {/each}
</ul>

从点击事件触发，到 Svelte 逻辑运行完，再到浏览器重排重绘，总用时 18.88ms，其中 Svelte 的逻辑执行只花了 9.5ms：

同样的例子用 React 实现，触发点击后总用时 98.5ms，其中 React 的逻辑执行了 89.38ms：

在这个例子中，React性能比 Svelte 差了一个数量级。之所以会有这样的差别，很大一部分起因在于Svlete 在更新前就晓得状态变动时须要更新哪个组件。

而这所有的源头就在于Signal。

更好的 DX

更好的开发者体验次要体现在两方面：

1. Signal感知上下文环境的能力缩小了代码心智累赘

比方在 React 中，useEffect在应用时须要指明依赖的状态：

useEffect(() => {// ...state1, state2 变动后的逻辑}, [state1, state2])

如果采纳 Signal 的实现，状态能感知到本人在 useEffect 上下文环境，能够主动建设两者之间的分割，不必再放心少写依赖状态、闭包陷阱等问题，缩小心智累赘。

比方在 Vue 中，相似 useEffect(仅仅是性能相似，两者的用处其实是不同的) 的watch，就不须要显式指明依赖：

<script setup>
import {ref, watch} from 'vue'

const name = ref('')

watch(name, (newName, oldName) => {// ... 省略逻辑})
</script>

2. 缩小开发者性能优化的心智累赘

应用 Signal 的框架通常能取得不错的运行时性能，所以不须要额定的性能优化API。反观React，开发者如果遇到性能问题，须要手动调用性能优化API（比方React.memo、useMemo、PureComponent）。

总结

有以上这么多长处，难怪很多框架都应用了 Signal。那么React 对Signal是什么态度呢？

React团队成员对此的观点是：

1. 有可能引入相似 Signal 的原语
2. Signal性能的确好，但他不太合乎 React 的理念

React的理念能够用一句话概括：UI 反映状态在某一刻的快照。

既然是快照，那就不是部分的，而是个整体概念。在 React 中，状态更新会引起整个利用从新 render，就是对React 快照理念的最好诠释。

React现阶段的所有实现都是基于快照理念。所以，即便引入相似 Signal 的原语，可能也是相似 Mobx 这样的下层实现，而不是从底层重构。

我集体比拟偏向于认为：React团队抵赖 Signal 的长处，但因为积重难返，而且古代设施的性能通常是过剩的，所以性能问题并不是首要问题。

如果这个观点是正确的，那么 React 可能会在开发者体验（Signal的另一个长处）方面努致力。比方去年提出的 RFC: useEvent 可能就是这方面的一次尝试。