TC39全新提案【Signals】V0草案已公布，狀態(tài)管理將迎來全新革命？
Hello，大家好，我是 Sunday。
今天咱們來看 TC39 的新提案 Signals 信號。該提案主要應用在 狀態(tài)管理 相關的場景下，可以結合目前狀態(tài)管理工具（Vuex、Pinia、Redux、MobX 或者是單純的 ref（Vue3 中聲明響應式數(shù)據(jù)的方案） 等）實現(xiàn)全新的解決方案。
目前猶大也在 vue 官網(wǎng)中提供了 Connection to Signals（與信號 (signal) 的聯(lián)系） 的概念，并提到 Signal 的重要性
那么下面咱們就來看看這個 Signal 到底是個什么東西。
什么是 TC39 以及標準提案流程
想要了解 Signal 咱們先來看看 TC39 提案！
TC39 提案是指由ECMAScript（JavaScript的標準）技術委員會TC39（Technical Committee 39）提出的標準改進建議。TC39負責JavaScript語言的演進和標準化工作。一個提案從最初的想法到最終成為標準，需要經(jīng)過多個階段的審核和修改。以下是提案的各個階段：
- Strawman（稻草人階段）：這個階段是一個初步的想法，可能沒有具體的實現(xiàn)細節(jié)，目的是引發(fā)討論和反饋。
- Proposal（提案階段）：在這個階段，提案需要有一個詳細的規(guī)范描述，并且至少有一個實現(xiàn)。提案會在TC39會議上討論，若獲得足夠支持，則進入下一階段。
- Draft（草案階段）：在這個階段，提案已經(jīng)有了詳細的規(guī)范文檔，并且需要有至少兩個不同的實現(xiàn)。提案在這個階段需要進行更廣泛的測試和反饋。
- Candidate（候選階段）：提案在這個階段被認為是穩(wěn)定的，并且所有可能的改進建議已經(jīng)納入。規(guī)范文檔在這個階段已經(jīng)基本定型，剩下的工作主要是驗證和確保沒有遺漏的錯誤。
- Finished（完成階段）：提案在這個階段成為ECMAScript標準的一部分，將被正式發(fā)布。此時，提案的內容已經(jīng)被完全采納和記錄。
為什么需要 Signals（信號）
要開發(fā)復雜的用戶界面 (UI)，JavaScript 應用程序開發(fā)人員需要以高效的方式 存儲、計算、使狀態(tài)失效、同步并將狀態(tài)推送到應用程序的視圖層。UI 通常不僅僅涉及管理簡單的值，還經(jīng)常涉及渲染計算狀態(tài)，而計算狀態(tài)依賴于其他值或狀態(tài)的復雜樹，而這些值或狀態(tài)本身也是計算出來的。
Signals 的目標是提供用于管理此類應用程序狀態(tài)的基礎設施，以便開發(fā)人員可以專注于業(yè)務邏輯，而不是這些重復的細節(jié)。
咱們來看一個例子（基于 preact）：
import { signal } from "@preact/signals";
const count = signal(0);
// 通過訪問.Value讀取信號的值：
console.log(count.value); // 0
// 更新信號的值
count.value += 1;
// 訪問值也必須要有 .value
console.log(count.value); // 1通過以上代碼我們可以看出來 Signals 與 vue 中的 ref 使用是有些類似的。它們都需要通過一個方法進行初始化，同時訪問的時候需要 .value
Signals 與框架的關聯(lián)
除了我們剛才看到的 preact 之外，還有很多的框架也實現(xiàn)了 Signals。比如：
- Solid
- Angular
- Qwik
從根本上說，Signals 是與 Vue 中的 ref 相同的響應性基礎類型（再前面我們也看到了類似的代碼例子）。**Signals是一個在訪問時跟蹤依賴、在變更時觸發(fā)副作用的值容器。
這種基于響應性基礎類型的范式在前端領域并不是一個特別新的概念：它可以追溯到十多年前的 Knockout observables 和 Meteor Tracker 等實現(xiàn)。
Vue 的選項式 API 和 React 的狀態(tài)管理庫 MobX 也是基于同樣的原則，只不過將基礎類型這部分隱藏在了對象屬性背后。
