Signal：更多前端框架的選擇

大家好，我卡頌。

最近，Angular、Qwik的作者**「MIŠKO HEVERY」**發文表示 Signal 是前端框架的未來 [1]，並考慮在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實現的框架會有兩個優勢：

更好的細粒度更新性能

由於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>
  1. 減少開發者性能優化的心智負擔

使用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[2] 可能就是這方面的一次嘗試。

參考資料

[1]

Signal 是前端框架的未來: https://www.builder.io/blog/usesignal-is-the-future-of-web-frameworks#code-use-ref-code-does-not-render

[2]

RFC: useEvent: https://github.com/reactjs/rfcs/pull/220

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/UDv4loT8iaTgkeFjeq-T-w

猜你喜歡