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