什么是響應性？

在過去的幾年中，響應性成為了所有現(xiàn)代前端框架以及React庫的核心。

對于不熟悉前端開發(fā)的人來說，起初這可能是一個令人困惑的概念，因為它改變了常規(guī)的、自上而下的、從調用者到被調用者的順序工作流。

在響應性范式中，當事情發(fā)生變化時，數(shù)據(jù)會自動更新，下面簡單展示一下偽代碼：

effect: console.log(x+2)
x = 2
x = 3

這種方法允許開發(fā)者以一種更直觀的方式處理數(shù)據(jù)和UI的更新，使得用戶界面能夠實時反映底層數(shù)據(jù)的變化。

根據(jù)響應性范式，應用程序可以在變量x發(fā)生變化時，無需程序員的特別努力，就能顯示NaN、4和5等多種結果。

這里極度簡化了這個話題，只是為了給那些對響應性一無所知的人一個大致的了解。

需要指出的是，響應性在前端開發(fā)中的許多情況下都非常有用。例如，在顯示用戶界面時，一個框架可以識別變量何時發(fā)生變化以更新用戶界面。比如當你展示一個實時的溫度計時。

響應性的應用場景遠不止于此，幾乎所有的前端框架都在使用響應性技術。甚至還有一個響應式的jQuery庫。

如何實現(xiàn)響應性？

響應性在實際應用中的一個很好的例子是電子表格。當你在電子表格中基于其他單元格的值輸入一個計算公式時，你不需要手動更新計算結果。電子表格應用會自動檢測到變化，并更新所有基于修改過的單元格的計算值。

在前端框架中，實現(xiàn)響應性有多種方法。一個著名的例子是使用RxJS，它依賴于觀察者（Observables）、訂閱者（Subscribers）和主題（Subjects）。如果你經(jīng)常處理異步數(shù)據(jù)流，這是一個很棒的庫。

在各種框架中，響應性的復雜性對開發(fā)者來說是隱藏的。

在React中，你必須明確提供依賴列表：

圖片

一旦reactive roomId 或 serverUrl 發(fā)生變化，上面的代碼片段將會斷開當前房間并連接到新的房間。

在Vue中，你甚至不需要提供依賴列表：

圖片

Vue會自行判斷，如果copy.count發(fā)生變化，就應該重新運行代碼。

如果我們審視所有主要的框架和庫，會發(fā)現(xiàn)每個框架和庫中的響應性幾乎達到了相同的API水平，并且從用戶的角度看幾乎在做相同的事情。

Signals 的起源如何？

Angular進行的最后一次主要切換到類似的API是在2023年4月3日發(fā)布的一份RFC中詳細說明的。該文檔深入探討了為什么zone.js的反應性不足，并且Angular必須轉向更細粒度的Signals。

并不是說Signals在這方面完全是新事物，更多的是基于研究如何以最佳方式提供響應性的結論。我真的認為應該將Signals的來源歸功于Solid。

自從那次重大工作完成以后，它鞏固了整個社區(qū)對細粒度響應性的采納。因為從那時起我們知道，幾乎每個框架和庫都使用幾乎相同的響應性模型，但有些用的是tomato，有些則用的是tomato。

推動 Signal 標準化的努力

考慮到這一點，我們可以想象許多可能的結果。一切可能維持現(xiàn)狀，每個框架使用自己的響應性模型。在這種情況下，人們實際上在使用不同名稱下的相同事物。

另一個情景是，每個人突然使用提供響應性模型的庫。到目前為止，這還沒有發(fā)生，但它仍然是桌面上的一個選項。

第三個，也是最瘋狂的情景，將是將 signals 納入 Ecmascript 本身。這意味著它將成為 JavaScript 本身的一部分。

聽起來瘋狂嗎？

確實。

但一切都在2023年2月一次偶然的 Twitter 聊天中浮出水面：每個人已經(jīng)有或正在調整響應模型以基于 Signals 的模型。參與討論的人之一是 Daniel Ehrenberg。

在過去的一年中，你真的不知道是否有什么事情正在醞釀，直到一個月前。

那時，Daniel 在紐約提議了一個名為 queerjs 的演講，這個名字相當令人費解：

他提供了一個相當引人入勝的描述：

一種選擇是通過使 Signals 內置到 JavaScript 中，如 Promises，來穩(wěn)定生態(tài)系統(tǒng)，提高性能和互操作性。但是...最好避免像 Promises 那樣的一些陷阱，例如它們始終開啟的調度器。

這意味著，Daniel 真的在考慮 Signals 是否應該成為 JavaScript 的一部分！

Signals可能會成為JavaScript的一部分

總的來說，這些都還只是討論階段。但是在JavaScript世界里，事情發(fā)展迅速。甚至比C++成為一種內存安全的編程語言還要快，這是肯定的！

兩天前，Daniel提議在4月的TC39會議上討論這個主題。這意味著它可能很快就會進入第一階段！

這是一件大事，因為TC39，即技術委員會39，負責標準化Ecmascript，而一旦某樣東西成為標準的一部分，遲早會成為JavaScript的一部分！

當然，這不會像在周五晚上發(fā)布到生產(chǎn)環(huán)境那么簡單。

Signals 可能需要時間才能成為 JavaScript 的標準功能

Signals 要成為 JavaScript 的標準功能，需要經(jīng)過六個標準化階段。因此，鑒于 Signals 的復雜性和響應性，這對整個委員會來說是一項艱巨的工作。但同時，它也將吸引包括前端框架開發(fā)者在內的許多開發(fā)者的關注。

在最佳情況下，他們所有人都應該滿意于將來某天切換到 Signals。

但這需要仔細的工作和解決許多難題。例如，標準應該是開放的還是封閉的。

展望未來幾年，我們可能會發(fā)現(xiàn)每個框架都使用標準的 JavaScript Signals。

這將有助于提高性能、可維護性，并能夠將知識從一個框架轉移到另一個框架。

許多好處確實可以讓這種努力變得值得。

同時，這個過程也可能在任何時候被終止，所以目前一切皆有可能。

然而，我無法停止這種感覺，現(xiàn)在是推動 Signals 前進的絕佳時機。特別是知道從2024年3月18日開始，還有一個Observable/Subscription模型的孵化過程，Signals 可以從中受益。

Signal 提案剛剛發(fā)布！

Rob Eisenberg 和 Daniel Ehrenberg 剛剛發(fā)布了 Signal 標準的第0階段提案。

已經(jīng)有一個 polyfill 可供測試，而這個提案已經(jīng)秘密開發(fā)了8個月！

作者成功地吸引了來自各種框架和庫的作者參與：

他們在這里合作，開發(fā)了一個可以支持他們核心響應性需求的通用模型。當前的草案基于來自 Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz 等作者/維護者的設計輸入。

以下是一個如何使用 Signals 的例子：

const counter = new Signal.State(0);
const isEven = new Signal.Computed(
  () => (counter.get() & 1) == 0);
const parity = new Signal.Computed(
  () => isEven.get() ? "even" : "odd");

// 庫或框架定義基于其他 Signal 原語的效果
declare function effect(cb: () => void): 
  (() => void);

effect(() => element.innerText 
  = parity.get());

// 模擬對計數(shù)器的外部更新...
setInterval(() => counter.set(
  counter.get() + 1), 1000);

這是多么令人震驚的簡單易用?。?/p>