兩年過去了，React Forget 涼了么？
大家好，我卡頌。
在 2 年前的React Conf 2021[1]，黃玄第一次介紹了React Forget，這是個「可以生成等效于 useMemo、React.memo」的編譯器（可以簡單理解為，有了它，開發者不需要考慮React項目的性能優化了）。
由于React獨特的架構（全局更新），「React 性能優化」一直讓開發者頭疼，這里主要有兩個問題：
- 很多開發者不知道如何正確使用性能優化API，甚至有人認為FC（函數組件）中所有函數都應該包裹在useCallback中
- 即使寫出性能優秀的項目，隨著需求迭代，新增的代碼很可能破壞之前的優化效果
所以，React Forget的愿景一經宣傳，就受到社區極大的關注。從React Conf 2021油管播放量來看，React Forget演講占了所有 19 個演講總播放量的 1/4（當然，也可能是因為黃玄長得帥）。
現在2年過去了，我們很少聽到React Forget的進展，黃玄也離開「React 團隊」了。這讓我們不禁要問，React Forget涼了么？
本文會聊聊React Forget當前的進展、接下來的發展方向，以及他的工作原理。
React Forget 涼了么？
首先要明確的是，React Forget并沒有涼，相反，他正在穩定迭代。
根據React團隊成員「Mofei Zhang」在React Advanced London 2023[2]的演講指出，「React 團隊」出品的所有產品，都會經歷 5 個階段：
- 理念驗證
- 產品實現
- Meta內部挑選業務線，小范圍使用
- 推廣到Meta其他業務線
- 發布開源版本
當前React Forget正處在階段 3，已經在下述兩個產品的生產環境投入使用：
- quest store[3]，Meta旗下VR產品的應用商店，基于React Native開發。
- instagram[4]，web項目，基于React DOM開發。
效果如何呢？以quest store舉例。下圖是quest store的產品詳情頁（由React Native實現）：
quest store產品詳情頁
可以看到，這是個左右布局的項目，點擊左側Tab右邊會有相應變化。
下圖是使用React Forget前，通過React Profiler測量的「點擊左側 Tab 觸發更新」后的更新火炬圖，其中：
- 每個小塊代表一個組件。
- 綠色小塊代表「觸發本次更新后，會 render 的組件」。
- 灰色小塊代表「觸發本次更新后，不會 render 的組件」（命中性能優化）。
顯然，當觸發更新后，灰色小塊越多，項目性能越好。
當項目經過React Forget編譯優化后，執行同樣操作的更新火炬圖如下（其中紅框內是優化的部分。也就是說，經過優化后，觸發同樣的操作，紅框內的組件都不會render了）：
這個優化效果有多好呢？數值如下：
- 「切換 Tab 操作」的響應速度提高 150%
- 頁面加載速度提高 4-12%
這里需要指出的是，經由React Forget生成的優化代碼等效于useMemo、React.memo這樣的「緩存 API」，而這些API主要是減少rerender過程中render的組件數量。
雖然「頁面加載」主要是首屏渲染（mount），此時這些緩存API發揮不了作用。但要完成頁面加載，很多組件是需要rerender的。舉個例子，對于列表的渲染，包括兩個步驟：
- 首屏渲染（mount），渲染空列表
- 獲取到數據后，渲染（rerender）包含數據的列表
所以，React Forget通過提高rerender速度，提高了頁面加載速度。
有同學可能會質疑 —— 是這個項目本身做的優化太少了，才顯得優化效果好吧？
首先，我們可以從優化前的火炬圖的灰色部分（下圖綠框內）看出，項目是經過性能優化的（否則應該都是綠色小塊）：
但是，一個精心優化過性能的React項目，就像撲克搭的城堡，任何風吹草動都能讓優化效果付之東流：
舉個例子，假設項目中有個很耗性能的組件ExpensiveCpn：
<ExpensiveCpn data={data}/>你將ExpensiveCpn用React.memo包裹，將data用useMemo包裹，使得ExpensiveCpn非必要不render。
但是，團隊其他成員接到需求，要給ExpensiveCpn增加個新props：
<ExpensiveCpn data={data} items={items}/>由于新加的items props沒有用useMemo包裹，使得你的優化失去效果（在復雜項目中，這種情況很常見）。
這就造成個悖論 —— 越是訪問量大、迭代頻繁、性能敏感的React項目，越難維持優秀的性能。
從這個角度看，React Forget意義重大。
為什么迭代這么慢？
既然React Forget這么重要，為什么這兩年都沒啥消息呢？因為JS作為動態語言語法太靈活，這極大增加了編譯器的開發難度。
根據從Chrome跳槽到「React 團隊」的工程師「Sathya Gunasekaran」在React India 2023[5]演講中表示：在React Forget中實現Alias Analysis（別名分析）的難度，比在Chrome V8中還高。
好在React作為一種DSL，相比純JS實現的項目多了很多約束，使得靜態分析成為可能，比如：
React組件類似于純函數，這意味著相同的輸入（props）會獲得相同的輸出（JSX返回值）。
這使得每個組件都是一個可以獨立靜態分析的模塊（不需要考慮組件之間互相影響）。同時，React Forget也能并行分析多個組件。
FC（函數組件）的大規模使用。
Class Component中所有屬性、方法都綁定在this中，比如：
- this.state
- this.setState
開發者也能在this上掛載屬性，這種靈活性為靜態分析帶來很大難度。
隨著Hooks普及，新的React項目基本都基于FC實現，排除了this的影響。
Hooks。
「在 FC 中，以 use 開頭的函數都是 hook」，這條規定為靜態分析提供了線索，比如：
- 考慮副作用時，需要分析useEffect等
- 考慮狀態時，需要分析useState等
Immutable state（不可變狀態）。
狀態不可變，意味著編譯器不需要考慮下面這種情況：
function App() {
const [num, update] = useState(0);
num = 2;
// ...
}工作原理
需要明確一點，React Forget可以生成等效于useMemo、React.memo的代碼，并不意味著編譯后的代碼會出現上述API，而是會出現「效果等效于上述 API」的輔助代碼。
舉個例子，考慮下面的代碼。VideoTab組件會根據filter過濾出videos數組中「符合條件的 video」，并渲染頭組件（Heading）與列表組件（VideoList）：
function VideoTab({heading, videos, filter}) {
const filterdList = [];
for (const video of videos) {
if (applyFilter(video, filter)) {
filterdList.push(video);
}
}
if (filterdList.length === 0) {
return <NoVideos />;
}
return (
<>
<Heading
heading={heading}
count={filterdList.length}
/>
<VideoList videos={filterdList} />
</>
)
}其中VideoList組件已經被React.memo包裹：
const VideoList = React.memo(/* 省略 */)當前，雖然VideoList組件不依賴heading props，但是heading props變化也會導致VideoTab組件render（因為每次render時都會生成新的filterdList）。為了優化他，可以用useMemo包裹filterdList：
const filterdList = useMemo(() => {
/* 省略 */
}, [videos, filter])只有當videos props或filter props變化時filterdList才會變化，就排除了heading props變化對VideoList組件的影響。
上述優化是開發者手動性能優化時會寫出的代碼。
如果交給React Forget，他會生成類似如下代碼。其中：
- 緩存被保存在名為useMemoCache的原生hook中。
- if else起到了等效useMemo的作用。
function VideoTab({heading, videos, filter}) {
const $ = useMemoCache(12);
let filterdList;
// 下面的if else起到了useMemo的效果
if ($[0] !== videos || $[1] !== filter) {
filterdList = [];
for (const video of videos) {
if (applyFilter(video, filter)) {
filterdList.push(video);
}
}
$[0] = videos;
$[1] = filter;
$[2] = filterdList;
} else {
filterdList = $[2];
}
// ...省略
}為什么不直接生成useMemo代碼呢？主要有兩個原因：
對于一個FC，大部分原生Hook的數據會保存在一條單向鏈表中（這也是「不能在條件語句中寫 Hooks」的原因），會占用更多內存。
在React Forget生成的代碼中，緩存保存在useMemoCache中，通過觀察useMemoCache 的源碼[6]可以發現，在useMemoCache內部，并不依賴單向鏈表保存數據。
這也意味著useMemoCache可以不遵守「不能在條件語句中寫 Hooks」這條規定。
useMemo內部需要對依賴項進行淺比較。
相比于淺比較，React Forget生成的if語句能直接被「JS 引擎」優化，更高效。
雖然React Forget的工作原理看似簡單，但考慮到大量的邊界情況，實際實現起來會很復雜。
舉個例子，考慮下面的代碼：
function Parent({a, b}) {
const x = [];
x.push(a);
return <Child x={x} />;
}要優化上述代碼很簡單，優化結果如下（這里用「性能優化 API」演示優化效果，方便理解意思）：
function Parent({a, b}) {
const x = useMemo(() => {
const x = [];
x.push(a);
return x;
}, [a])
return <Child x={x} />;
}現在，我們新增兩行代碼：
function Parent({a, b}) {
const x = [];
x.push(a);
// 下面兩行是新增代碼
const y = x;
y.push(b);
return <Child x={x} />;
}按照優化邏輯，下面是優化后的代碼：
function Parent({a, b}) {
const x = useMemo(() => {
const x = [];
x.push(a);
return x;
}, [a])
const y = useMemo(() => {
const y = x;
y.push(b);
return y;
}, [x, b])
return <Child x={x} />;
}現在問題來了，優化前后的代碼邏輯相同么？你可以仔細觀察下。
答案是 —— 不相同。
優化后，在首次render時，x、y都會指向數組[a, b]，如下圖：
假設b發生變化，觸發新的更新，由于x依賴a，所以x不變，仍為[a, b]。
而y依賴了b，所以y變化，render后x、y的指向如下：
按照優化前的邏輯，結果應該如下：
類似這樣的邊界情況還很多。為了保證編譯后的邏輯和編譯前相同，「React 團隊」為React Forget寫了 500 多個用例。
總結
React Forget當前仍處在Meta內部少數業務線的驗證階段，接下來會在公司內部更多業務線鋪開。當完成上述流程后，會向社區開放。
你覺得React Forget前景怎么樣？歡迎評論區討論。
這里插個好玩的事兒，在React Advanced London演講現場有觀眾提問：既然React Forget是用來緩存數據的，為啥不叫React Remember？
我以為演講者會說：項目初衷是為了讓開發者忘記（forget）寫性能優化API。
結果他說：因為團隊有個慣例 —— 用F words命名項目，Remember顯然不是F開頭的。
WTF？？？？？
參考資料
[1]React Conf 2021:https://www.youtube.com/watch?v=lGEMwh32soc。
[2]React Advanced London 2023:https://www.youtube.com/watch?v=hn_L56ypX1A。
[3]quest store:https://www.meta.com/experiences/。
[4]instagram:instagram.com。
[5]React India 2023:https://www.youtube.com/watch?v=JuedZFbhyL0&t=1522s。
[6]useMemoCache 的源碼:https://github.com/facebook/react/blob/main/packages/react-reconciler/src/ReactFiberHooks.js#L1112-L1169。
