苦等三年，React Compiler 終于能用了。使用體驗：很爽，但仍有瑕疵
一、React Compiler
React Compiler 終于開源了。
自從從它第一次在 React Conf 2021 亮相。到現在 React Conf 2024 正式開源，我已經苦等了三年之久。盼星星盼月亮，終于把他給盼來了。
i
以前叫 React Forget，現改名為 React Compiler。
要了解 React Compiler，這還需要從 React 的更新機制說起。React 項目中的任何一個組件發生 state 狀態的變更，React 更新機制都會從最頂層的根節點開始往下遞歸對比，通過雙緩存機制判斷出哪些節點發生了變化，然后更新節點。這樣的更新機制成本并不小，因為在判斷過程中，如果 React 發現 props、state、context 任意一個不同，那么就認為該節點被更新了。因此，冗余的 re-render 在這個過程中會大量發生。
?
對比的成本非常小，但是 re-render 的成本偏高，當我們在短時間之內快速更改 state 時，程序大概率會存在性能問題。因此在以往的開發方式中，掌握性能優化的手段是高級 React 開發者的必備能力。
一個組件節點在 React 中很難被判斷為沒有發生過更新。因為 props 的比較總是不同的。它的比較方式如下。
{} === {} // false因此，高級 React 開發者需要非常了解 React 的默認優化機制，讓 props 的比較不發生，因為一旦發生，那么結果必定是 false。
i
事實上，對 React 默認優化機制了解的開發者非常少，我們在開發過程中也不會為了優化這個性能去重新調整組件的分布。更多的還是使用 memo 與 useMemo/useCallback 暴力緩存節點。
在這樣的背景之下，冗余的 re-render 在大量的項目中發生。這也是為什么 React 總是唄吐槽性能不好的主要原因。當然，大多數項目并沒有頻繁更新 state 的需求，因此這一點性能問題表現得并不是很明顯。
如果我們要解決冗余 re-render 的問題，需要對 React 默認優化技能有非常深刻的理解，需要對 memo、useCallback、useMemo 有準確的理解。但是普通的 React 開發者很難理解他們，有的開發者雖然在項目中大量使用了，但是未必就達到了理想的效果。React Compiler 則是為了解決這個問題，它可以自動幫助我們記憶已經存在、并且沒有發生更新的組件，從而解決組件冗余 re-render 的問題。
從使用結果的體驗來看，React Compiler 被集成在代碼自動編譯中，因此只要我們在項目中引入成功，就不再需要關注它的存在。我們的開發方式不會發生任何改變。它不會更改 React 現有的開發范式和更新方式，侵入性非常弱。
二、檢測
并非所有的組件都能被優化。因此早在 React 18 的版本中，React 官方團隊就提前發布了嚴格模式。在頂層根節點中，套一層 StrictMode 即可。
<StrictMode>
<BrowserRouter>
<App />
</BrowserRouter>
</StrictMode>遵循嚴格模式的規范，我們的組件更容易符合 React Compiler 的優化規則。
我們可以使用如下方式首先檢測代碼庫是否兼容。在項目根目錄下執行如下指令。
npx react-compiler-healthcheck?
該腳本主要用于檢測。
1、項目中有多少組件可以成功優化：越多越好。
2、是否使用嚴格模式，使用了優化成功率更高。
3、是否使用了與 Compiler 不兼容的三方庫。
例如，我的其中一個項目，檢測結果如下：
每一項都基本上通過了，那我就可以放心的在項目中引入對應的插件開始體驗了。
三、在項目中引入
官方文檔中已經明確表示，由于 JavaScript 的靈活性，Compiler 無法捕獲所有可能的意外行為，甚至編譯之后還會出現錯誤。因此，目前而言，Compiler 依然可能會有他粗糙的一面。因此，我們可以通過配置，在具體的某一個小目錄中運行 Compiler。
const ReactCompilerConfig = {
sources: (filename) => {
return filename.indexOf('src/path/to/dir') !== -1;
},
};React Compiler 還支持對應的 eslint 插件。該插件可以獨立運行。不用非得與 Compiler 一起運行。
可以使用如下指令安裝該插件。
npm i eslint-plugin-react-compiler然后在 eslint 的配置中添加。
module.exports = {
plugins: [
'eslint-plugin-react-compiler',
],
rules: {
'react-compiler/react-compiler': 2,
},
}Compiler 目前結合 Babel 插件一起使用，因此，我們首先需要在項目中引入該插件。
npm i babel-plugin-react-compiler然后，在不同的項目中，有不同的配置。
添加到 Babel 的配置中，如下所示
module.exports = function () {
return {
plugins: [
['babel-plugin-react-compiler', ReactCompilerConfig], // must run first!
// ...
],
};
};i
注意，該插件應該在其他 Babel 插件之前運行。
在 vite 中使用
首先，我們需要安裝 vite-plugin-react，注意不用搞錯了，群里有的同學使用了 vite-plugin-react-swc 結果搞了很久沒配置成功。然后在 vite.config.js 中，添加如下配置。
export default defineConfig(() => {
return {
plugins: [
react({
babel: {
plugins: [
["babel-plugin-react-compiler", ReactCompilerConfig],
],
},
}),
],
// ...
};
});在 Next.js 中使用
創建 babel.config.js 并添加上面 Babel 同樣的配置即可。
在 Remix 中使用
安裝如下插件，并且添加對應的配置項目。
npm i vite-plugin-babel// vite.config.js
import babel from "vite-plugin-babel";
const ReactCompilerConfig = { /* ... */ };
export default defineConfig({
plugins: [
remix({ /* ... */}),
babel({
filter: /\.[jt]sx?$/,
babelConfig: {
presets: ["@babel/preset-typescript"], // if you use TypeScript
plugins: [
["babel-plugin-react-compiler", ReactCompilerConfig],
],
},
}),
],
});在 Webpack 中使用
我們可以單獨為 Compiler 創建一個 Loader. 代碼如下所示。
const ReactCompilerConfig = { /* ... */ };
const BabelPluginReactCompiler = require('babel-plugin-react-compiler');
function reactCompilerLoader(sourceCode, sourceMap) {
// ...
const result = transformSync(sourceCode, {
// ...
plugins: [
[BabelPluginReactCompiler, ReactCompilerConfig],
],
// ...
});
if (result === null) {
this.callback(
Error(
`Failed to transform "${options.filename}"`
)
);
return;
}
this.callback(
null,
result.code
result.map === null ? undefined : result.map
);
}
module.exports = reactCompilerLoader;我們可以在 React 官方了解到更多關于 React Compiler 的介紹與注意事項。具體地址如下：https://react.dev/learn/react-compiler
我目前已經在 vite 項目中引入，并將項目成功啟動。接下來，就談談我的使用體驗。
四、真實項目的使用體驗
當項目成功啟動，之后，我們可以在 React Devtools v5.x 的版本中，看到被優化過的組件旁邊都有一個 Memo 標識。如圖所示。
如果我們要運行 React Devtools，安裝成功之后，需要將如下代碼加入到 html 文件中。這樣我們就可以利用它來調試 React 項目了。
<script src="http://localhost:8097"></script>
如果是已有的老項目，我們最好刪除 node_modules 并重新安裝以來。不然項目運行起來可能會報各種奇怪的錯誤。如果還是不行，可以把 React 版本升級到 19 試試。
總之折騰了一會兒，我成功運行了一個項目。我目前就寫了一個簡單的組件來測試他的優化效果。代碼如下：
function Index() {
const [counter, setCounter] = useState(0)
function p() {
console.log('函數執行 ')
}
return (
<div>
<button onClick={() => setCounter(counter + 1)}>
點擊修改 counter：{counter}
</button>
<Children a={1} b={2} c={p} />
</div>
)
}我們先來分析一下這段代碼。首先，在父組件中，我們設計了一個數字遞增的狀態。當點擊發生時，狀態遞增。此時父組件會重新 render。因此，在以往的邏輯中，子組件 Children 由于沒有使用任何優化手段，因此，在父組件重新渲染時，子組件由于 props 的比較結果為 false，也會重新執行。
并且其中一個 props 屬性還是一個引用對象，因此我們需要使用 useCallback + memo 才能確保子組件 Children 不會冗余 re-render。
但是此時，我們的組件已經被 React Compiler 優化過，因此，理論上來說，冗余 re-render 的事情應該不會發生，嘗試了一下，確實如此。如圖，我點擊了很多次按鈕，counter 遞增，但是 Children 并沒有冗余執行。
很棒。
這里需要注意的是，引入了 Compiler 插件之后，它會自動工作，我們完全不用關注它的存在。因此，如果程序不出問題，對于開發者來說，編譯工作是無感的。所以開發體驗非常棒。
!
不過有一些美中不足的是，當我嘗試驗證其他已經寫好的組件被編譯之后是否存在問題時，發現有一個組件的運行邏輯發生了變化。目前我還沒有深究具體是什么原因導致的，不過通過對比，這個組件的獨特之處在與，我在該組件中使用了 useDeferredValue 來處理異步請求。
另外，Compiler 也不能阻止 context 組件的 re-render。例如我在一個組件中使用了 use(context) ，哪怕我并沒有使用具體的值。如下所示。
import {use} from 'react'
import {Context} from './context'
export default function Card() {
const value = use(Context)
console.log('xxxxx context')
return (
<>
<div className='_06_card'>
<div className="title">Canary</div>
<p>The test page</p>
</div>
</>
)
}理想情況是這種情況可以不用發生 re-render。因此總體來說，Compiler 目前確實還不能完全信任。也有可能我還沒掌握正確的姿勢，還需要對他有更進一步的了解才可以。
不過值得高興的是，新項目可以放心使用 Compiler，因為運行結果我們都能實時感知、調試、調整，能最大程度的避免問題的出現。
五、原理
React Compiler 編譯之后的代碼并非是在合適的時機使用 useMemo/memo 等 API 來緩存組件。而是使用了一個名為 useMemoCache 的 hook 來緩存代碼片段。
Compiler 會分析所有可能存在的返回結果，并把每個返回結果都存儲在 useMemoCache 中。如上圖所示，他打破了原有的鏈表存儲結果，而選擇把緩存結構存儲在數組上。因此在執行效率上，Compiler 之后的代碼會高不少。每一個渲染結果都會被存儲在 useMemoCache 的某一項中，如果判斷之后發現該結果可以復用，則直接通過讀取序列的方式使用即可。如圖所示。
因此，編譯之后的代碼看上去會更加的繁雜。但是執行卻會更加高效。
六、總結
初次感受下來，雖然感覺還不錯。但是依然會有一種自己寫的代碼被魔改的不適感。特別是遇到問題的時候，還不知道到底編譯器干了什么事情讓最終運行結果與預想的完全不同。
i
這也是我不太喜歡使用 Solid 與 Svelte 的根本原因。不過 React 好在可以不用...
但是從執行性能上確實會有大的提高，這一點對于初學者可能會比較友好。
目前，由于接觸時間太短，我對于 React Compiler 的使用體驗還停留在比較淺的層面。因此能聊的東西并不多，在后續我有了更進一步更深刻的體會之后，再來跟大家分享體驗結果。
