探索主流前端框架的響應式原理！
本文將探索主流前端框架中的響應式是如何工作的并比較這些框架的不同之處以更好地理解它們。
前置準備
響應式
響應式可以被廣義地定義為應用狀態變化時自動更新UI。作為開發者，我們只需要關注應用的狀態，并讓框架將該狀態反映到UI 上。但是，框架如何反映該狀態可能會對代碼的性能和懶加載產生影響，下面會進行深入探討。
粗粒度 vs 細粒度
在響應式框架之間進行比較的一個維度是粗粒度與細粒度的響應性。
- 粗粒度：框架必須執行大量應用或框架代碼來確定哪些 DOM 節點需要更新。
- 細粒度：框架不需要執行任何代碼，就知道哪些 DOM 節點需要更新。
這是一個框架可以處于連續的維度，不過僅僅是眾多可以比較的維度之一。本文中也將涉及渲染。在這里，渲染意味著框架確定要更新哪個 DOM 的方式，而不是瀏覽器因 DOM 更新而執行的實際瀏覽器渲染。
下面是跟顆粒度得出的一個結論（從左到右表示粗粒度到細粒度）：
注意：這并不是一個權威的結果，所以接下倆將深入討論如何得出這些結論的，也許你會得出不同的結論。
測試應用
在深入討論如何得出這些結論之前，需要定義一些標準，然后根據這些標準來比較框架之間的響應式行為。從最簡單的應用開始：計數器。計數器需要狀態、事件處理和到 DOM 的綁定。
這個例子比較簡單。在實際的應用中，狀態、事件和綁定并不總是在同一個組件中。因此，我們將示例分解成更細粒度的組件，以展示狀態存儲（Counter）、狀態修改（Incrementor）和狀態綁定（Incrementor）是如何跨多個組件進行分布的。
接下來引入一個 Wrapper 組件，它是惰性的，僅用于將狀態從父組件 Counter 傳遞到子組件 Display。在現實的應用中，惰性組件很常見，我們想看看框架如何處理它們。
注意： 大多數前端框架提供了機制來優化它們的響應式能力。但是，本文主要探討框架“開箱即用”的行為，因此這些優化超出了討論的范圍。
React 和 Angular
React 和 Angular 都是粗粒度的，因為狀態的改變需要重新執行組件樹。所謂重新執行，是指需要重新運行關聯組件的應用代碼，以便框架檢測更改，以便它可以更新 DOM。
在 React 中，需要重新運行組件以重新創建 vDOM，然后將其與之前的 vDOM 進行比較以確定需要更新哪些 DOM 元素。在 Angular 中，組件需要重新讀取表達式以確定是否需要更新 DOM。
實際上，框架并不知道哪個狀態綁定到了哪個 DOM 元素上，框架需要比較當前和以前的 vDOM（或值）以檢測變化。
React 示例代碼如下：
import * as React from 'react';
import { useState } from 'react';
export default function Counter() {
const [count, setCount] = useState(0);
return (
<section>
<h1><Counter>: {appCounter()}</h1>
<Wrapper value={count} />
<Incrementor setCount={setCount} />
</section>
);
}
function Wrapper({ value }: { value: number }) {
return (
<section>
<h1><Wrapper>: {wrapperCounter()}</h1>
<Display value={value} />
</section>
);
}
function Display({ value }: { value: number }) {
return (
<section>
<h1><Display>: {displayCounter()}</h1>
<main>{value}</main>
</section>
);
}
function Incrementor({
setCount,
}: {
setCount: (fn: (v: number) => number) => void;
}) {
return (
<section>
<h1><Incrementor>: {incrementorCounter()}</h1>
<button onClick={() => setCount((v) => v + 1)}>+1</button>
</section>
);
}
const appCounter = makeCounter();
const wrapperCounter = makeCounter();
const displayCounter = makeCounter();
const incrementorCounter = makeCounter();
function makeCounter() {
let count = 0;
return () => `(re-render count: ${++count})`;
}示例效果如下：
在線體驗：https://stackblitz.com/edit/react-ts-zt2b5n。
Svelte
Svelte 使用編譯器將 .svelte 文件編譯成自定義代碼。編譯器在生成輸出代碼方面非常智能和高效。
在初始渲染中，Svelte 必須執行所有組件作為水合的一部分，這就是初始渲染計數為 1 的原因。但在后續交互中，計數不再更新。你可能會認為這是因為 Svelte 是細粒度響應式的，但實際上情況很微妙，讓我們深入挖掘一下。
在線示例：https://stackblitz.com/edit/vitejs-vite-bsox6f。
打開上面的示例，執行以下操作：
- 打開一個新的瀏覽器選項卡，以便調試；
- 接著打開瀏覽器的開發者工具；
- 禁用 source maps 以便可以獲取生成的代碼；
- 搜索 p: function以查找 Svelte 執行變更檢測的所有位置。
- 根據文件名向每個添加 log。例如：Render: Display。
當與 Svelte 應用進行交互時，單擊會導致Counter、Wrapper和Display重新執行，但不會重新執行Incermentor。
Render Counter
Render Wrapper
Render Display因此，盡管交互仍會導致組件重新執行，但 Svelte 比React（或Angular）更細粒度。但有一個重要的區別，就是 Svelte 示例沒有導致Incrementor重新執行。這是一項重要的優化，因為它允許 Svelte 在不涉及開發人員的情況下修剪樹的分支。在React（或Angular）中也可以實現此操作，但需要開發人員做更多的工作（并非“開箱即用”）。
Svelte編譯器在后臺會非常高效地進行臟檢查。它要求 Svelte 從更改所在的組件開始，然后訪問所有傳播更改的子組件，在上面示例中就是 Counter、Wrapper和Display。
這意味著代碼需要不斷重新執行，編譯器使其非常高效，在實踐中永遠不會成為性能瓶頸。但是，代碼不斷重新執行意味著所有位于渲染樹中的組件都不能被懶加載。
Svelte stores
現在 Svelte 編譯器只適用于.svelte 文件。這意味著如果想在 .svelte 文件之外實現響應式，就不能依賴編譯器。相反，Svelte 提供了一個單獨的機制，稱為 stores。
上面的 Svelte 示例中，下半部分就是使用 Store 編寫的相同應用。當與該應用交互并使用 log 進行測試時，可以看到 Svelte 只重新渲染Display組件，這表明 Svelte 在使用 Store 時比使用編譯器更高效（需要執行的代碼更少）。
執行更少的代碼意味著不需要下載不執行的代碼到客戶端。但是，水合會導致所有組件在啟動時至少運行一次，這意味著無法對渲染樹中的組件進行代碼懶加載。
Vue
Vue 與 Svelte 相似，它會重新運行組件。單擊+1按鈕會導致Counter、Wrapper和Display重新渲染。與 Svelte 不同的是，Vue 不是基于編譯器的響應式，而是基于運行時的。Vue 將響應式原語稱為 Refs，它與后面將要討論的 Signals 類似。
在線示例：https://stackblitz.com/edit/vitejs-vite-aamf2c。
Vue 可以跨組件邊界傳遞響應式原語。它可以通過 Wrapper 將 Ref 從 Counter 傳遞到 Display。這樣做的結果就是，即使 Wrapper 只是一個傳遞，Wrapper 也必須參與 Display 的重新渲染。
Vue 也要求在啟動時進行水合，因此渲染樹中的所有組件都必須在啟動時執行一次。這意味著必須下載它們，這使得懶加載很困難。
Vue 依賴注入
Vue 可以通過使用 provide 和 inject API 將 Ref 從 Counter 傳遞到 Display，繞過 Wrapper。如第二個示例所示。在這種情況下，與應用交互只會導致 Display 重新執行，這是一種更高效的行為。
這種差異是在.vue文件中在組件之間傳遞值會導致Refs在組件邊界上取消包裝和重新包裝，但是provide/inject允許繞過此包裝行為，并直接傳遞Ref而不需要取消包裝，從而實現更細粒度的更新（類似于Svelte stores）。
Vue 比 Svelte 更具有響應式，因為它只有單一的響應式模型Ref，而不像 Svelte 那樣具有兩個。從.vue文件中移動代碼或移回.vue文件不需要進行任何響應式重構。
Qwik
到目前為止，當檢測到更改時，都必須至少重新執行一個組件，一個組件是最少的工作量。但是我們可以做得更好：DOM 級別的響應式。
Qwik 展示了 DOM 級別上的響應式。當與應用進行交互時，Signal 連接的不是關聯的組件，而是直接連接到 DOM 元素。更新 Signal 會直接更新 DOM 而無需執行關聯的組件。因為組件沒有執行，所以不必被下載。因此，節省的不是不執行組件而是不下載組件所帶來的。
另外值得注意的是，Qwik 不需要在啟動時執行水合。因為沒有水合，所以不需要執行任何代碼，因此也不需要下載任何代碼。
在線示例：https://stackblitz.com/edit/qwik-starter-9mbhi5。
在這個例子中，沒有在客戶端（點擊處理程序之外）下載或執行任何應用代碼。這是因為 Qwik 可以充分描述 Signal 和 DOM 之間的關系。這種關系是從在服務器上運行應用中提取的（因此應用不需要在瀏覽器中運行）。
Qwik 不能描述 Signals 中的結構變化。因此，對于結構更改（添加/刪除 DOM 節點），Qwik 就會下載并重新執行組件。
Solid
Solid 與 Qwik 一樣，將 Signal 直接與 DOM 更新聯系起來。但是，Solid 不僅可以對常規值進行此操作，還可以對結構性更改進行此操作。
在線示例：https://stackblitz.com/edit/solidjs-templates-rqp7kj。
Solid 只會執行一次組件，這些組件永遠不會再次執行。與其他框架一樣，Solid 需要在水合時執行一次組件，這意味著必須在應用啟動時下載和執行所有組件。
Solid 在響應式方面可能是最好的，因為它的響應式可能是最好的形式—— DOM 級別而非組件級別。但是，它仍然需要水合，這會導致代碼下載和執行。
對比
響應式方法
在前端框架中，一般有三種處理響應式的方法：
- Values: 通過比較當前值和之前的值來檢測數據變化。Angular 使用表達式進行比較，React 使用虛擬DOM進行比較，Svelte 使用編譯器進行臟數據標記。
- Observables：在 Angular 中使用RxJS，在Svelte中使用Stores來處理響應式數據。
- Signals：在 Vue、Qwik和 Solid 框架中使用 Signals。它與 Vue 相連的是組件，Qwik 與 DOM 連接，Solid 使用DOM作為更細粒度的方法。
每種方法都有其特點和適用場景，開發者需要根據具體情況選擇合適的方法來處理響應式數據。
組件層次結構
Angular、React、Svelte 和 Vue 在傳播對狀態的更改時遵循組件層次結構。（Svelte 和 Vue 也可以直接進行組件更新，但這些并不是“開箱即用”的）而且這些更新始終發生在組件級別。
Qwik 和 Solid 不遵循組件層次結構，而是直接更新 DOM。在結構變化方面，Solid 比 Qwik 有優勢。Solid 可以進行 DOM 更新，而 Qwik 是進行單個組件更新（不是組件樹）。
水合
Qwik 的獨特之處在于它是唯一不需要進行水合的框架。與其他框架不同，Qwik 不需要在啟動時執行所有組件來了解狀態如何連接到 DOM。Qwik 將該信息序列化為 SSR/SSG 的一部分，并能夠在客戶端上恢復。
這種可恢復性使 Qwik 具有獨特的優勢，因為 Qwik 不需要在啟動時下載大部分應用代碼。因此，雖然 Solid 比 Qwik 更細粒度，但 Qwik 的可恢復性使它更具優勢。
參考：https://www.builder.io/blog/reactivity-across-frameworks。
