說實話現在我很激動。

從 React Compiler 開源到現在我連續(xù)研究分析 React Compiler 已經四天時間了，這期間我積累了大量的使用心得，整體感受就是它真的太強了！

現在我迫不及待地想跟大家分享 React Compiler 的深度使用體驗。

這篇文章我會結合三個實踐案例為大家解讀 React Compiler 到底強在哪，這可能會有一點難理解，不過道友們請放心，我會做好知識鋪墊，盡量用更簡單的方式來表達。內容梗概如下：

• 如何查看編譯之后的代碼
• Symbol.for() 基礎介紹
• 實現原理詳細分析
• 實踐案例一：counter 遞增
• 實踐案例二：渲染成本昂貴的子組件
• 實踐案例三：Tab 切換
• 強悍的性能表現：超細粒度緩存式/記憶化更新
• 項目開發(fā)中，最佳實踐應該怎么做

經過驗證發(fā)現由于 React19 之前的版本內部不包含 compiler-runtime，因此無法正常使用，我猜測可能會在以后提供插件來支持編譯老版本的項目。目前我是在 React 19 RC 版本中結合 Compiler。不過好消息是將項目升級到 React 19 難度并不高。許多三方庫也已經積極的適配了 React 19。

一、如何查看編譯之后的代碼

通常情況下，你只需要在合適的位置打印一個 log。然后我們就可以通過下圖所示的位置，在 console 面板中，點擊跳轉到編譯之后的代碼。

當然，我們可以直接在 Sources 面板中查看。

除此之外，你也可以把代碼拷貝到 React Compiler Playground。這是一個在線的代碼編譯轉換工具。我們可以利用這個工具方便的將代碼轉換成 Compiler 編譯之后的代碼，學習非常方便。

React Compiler Playground 的在線地址如下。除此之外，如果你存在任何疑問，完整的鏈接可以包含你的具體案例，在溝通和交流上非常方便。你可以在 react 的 issue 里看到大量 Compiler 不支持的騷操作。

https://playground.react.dev/

知道了怎么查看編譯之后的代碼之后，那我們就需要看得懂才行。因此接下來。

二、Symbol.for

我本來最初的想法是看懂編譯之后的代碼不是很有必要。但是有的時候會出現一些情況，程序運行的結果跟我預想的不一樣。

出現這種迷惑行為的時候就感覺賊困惑，為啥會這樣呢？布吉島 ～，如何調整我自己的寫法呢？也不知道。我很不喜歡這種一臉懵逼的感覺。

看是得看懂才行。雖然這個代碼很不像是正常人應該去閱讀的代碼。先來感受一下編譯之后的代碼長什么樣。

在 Compiler 編譯后的代碼中，有一個比較少見的語法會頻繁出現：Symbol.for，我先把這個知識點科普一下。

Symbol 在 JavaScript 中，是一種基礎數據類型。我們常常用 Symbol 來創(chuàng)建全局唯一值。例如，下面兩個變量，雖然寫法是一樣的，但是他們的比較結果并不相等。

var a = Symbol('hello')
var b = Symbol('hello')

a === b // false

Symbol.for 則不同，Symbol.for 傳入相同字符串時，它不會重復創(chuàng)建不同的值。而是在后續(xù)的調用中，讀取之前已經創(chuàng)建好的值。因此下面的代碼對比結果為 true。

var a = Symbol.for('for')
var b = Symbol.for('for')

a === b // true

或者我們用另外一種說法來表達這種創(chuàng)建 -> 讀取的過程。

// 創(chuàng)建一個 symbol 并放入 symbol 注冊表中，鍵為 "foo"
Symbol.for("foo");

// 從 symbol 注冊表中讀取鍵為"foo"的 symbol
Symbol.for("foo");

在 Compiler 編譯后的代碼中，組件依賴 useMemoCache 來緩存所有運算表達式，包括組件、函數等。在下面的例子中，useMemoCache 傳入參數為 12，說明在該組件中，有 12 個單位需要被緩存。

在初始化時，會默認給所有的緩存變量初始一個值。

$ = useMemoCache(12)

for (let $i = 0; $i < 12; $i += 1) {
  $[$i] = Symbol.for("react.memo_cache_sentinel");
}

那么，組件就可以根據緩存值是否等于 Symbol.for 的初始值，來判斷某一段內容是否被初始化過。如果相等，則沒有被初始化。

如下：

let t1;

if ($[1] === Symbol.for("react.memo_cache_sentinel")) {
  t1 = <div id="tips">Tab 切換</div>;
  $[1] = t1;
} else {
  t1 = $[1];
}

三、緩存原理詳細分析

我們需要重新詳細解讀一下上面那段代碼。這是整個編譯原理的核心理論。對于每一段可緩存內容，這里以一個元素為例。

<div id="tips">Tab 切換</div>

我們會先聲明一個中間變量，用于接收元素對象。

let t1

但是在接收之前，我們需要判斷一下是否已經初始化過。如果沒有初始化，那么則執(zhí)行如下邏輯，創(chuàng)建該元素對象。創(chuàng)建完成之后，賦值給 t1，并緩存在 $[1] 中。

if ($[1] === Symbol.for("react.memo_cache_sentinel")) {
  t1 = <div id="tips">Tab 切換</div>;
  $[1] = t1;
}

如果已經初始化過，那么就直接讀取之前緩存在 $[1] 中的值即可。

...
} else {
  t1 = $[1];
}

這樣，當函數組件多次執(zhí)行時，該元素組件就永遠只會創(chuàng)建一次，而不會多次創(chuàng)建。

i

這里需要注意的是，判斷成本非常低，但是創(chuàng)建元素的成本會偏高，因此這種置換是非常劃算的，我們后續(xù)會明確用數據告訴大家判斷的成本

對于一個函數組件中聲明的函數而言，緩存的邏輯會根據情況不同有所變化。這里主要分為兩種情況，一種情況是函數內部不依賴外部狀態(tài)，例如：

function __clickHanler(index) {
  tabRef.current[index].appeared = true
  setCurrent(index)
}

那么編譯緩存邏輯與上面的元素是完全一致的，代碼如下：

let t0;

if ($[0] === Symbol.for("react.memo_cache_sentinel")) {
  t0 = function __clickHanler(index) {
    tabRef.current[index].appeared = true;
    setCurrent(index);
  };

  $[0] = t0;
} else {
  t0 = $[0];
}

另外一種情況是有依賴外部狀態(tài)，例如：

const [counter, setCounter] = useState(0)

// 此時依賴 counter，注意區(qū)分他們的細微差別
function __clickHanler() {
  console.log(counter)
  setCounter(counter + 1)
}

那么編譯結果，則只需要把是否重新初始化的判斷條件調整一下即可。

let t0;

if ($[0] !== counter) {
  t0 = function __clickHanler() {
    console.log(counter);
    setCounter(counter + 1);
  };

  $[0] = counter;
  $[1] = t0;
} else {
  t0 = $[1];
}

這樣，當 counter 發(fā)生變化，t0 就會重新賦值，而不會采用緩存值，從而完美的繞開了閉包問題。

除此在外，無論是函數、還是組件元素的緩存判斷條件，都會優(yōu)先考慮外部條件，使用 Symbol.for 來判斷時，則表示沒有其他任何值的變化會影響到該緩存結果。

例如，一個組件元素如下所示：

<button notallow={__clickHanler}>counter++</button>

此時它的渲染結果受到 __clickHanler 的影響，因此，判斷條件則不會使用 Symbol.for，編譯結果如下：

let t2;

if ($[3] !== __clickHanler) {
  t2 = <button onClick={__clickHanler}>counter++</button>;
  $[3] = __clickHanler;
  $[4] = t2;
} else {
  t2 = $[4];
}

又例如下面這個元素組件，他的渲染結果受到 counter 的影響。

<div className="counter">
  counter: {counter}
</div>

因此，它的編譯結果為：

let t3;

if ($[5] !== counter) {
  t3 = <div className="counter">counter: {counter}</div>;
  $[5] = counter;
  $[6] = t3;
} else {
  t3 = $[6];
}

對于這樣的編譯細節(jié)的理解至關重要。在以后的開發(fā)中，我們就可以完全不用擔心閉包問題而導致程序出現你意想不到的結果了。

所有的可緩存對象，全部都是這個類似的邏輯。他的粒度細到每一個函數，每一個元素。這一點意義非凡，它具體代表著什么，我們在后續(xù)聊性能優(yōu)化的時候再來明確。

不過需要注意的是，對于 map 的循環(huán)語法，在編譯結果中，緩存的是整個結果，而不是渲染出來的每一個元素。

{tabs.map((item, index) => {
  return (
    <item.component
      appearder={item.appeared}
      key={item.title}
      selected={current === index}
    />
  )
})}

編譯結果表現如下：

let t4;

if ($[7] !== current) {
  t4 = tabs.map((item_0, index_1) => (
    <item_0.component
      appearder={item_0.appeared}
      key={item_0.title}
      selected={current === index_1}
    />
  ));
  $[7] = current;
  $[8] = t4;
} else {
  t4 = $[8];
}

?

對這種情況的了解非常重要，因為有的時候我們需要做更極限的性能優(yōu)化時，map 循環(huán)可能無法滿足我們的需求。因為此時循環(huán)依然在執(zhí)行，后面的案例中我們會更具體的分析 Map 的表現

目前這個階段，我們最主要的是關心程序執(zhí)行邏輯與預想的要保持一致，因此接下來，我們利用三個案例，來分析編譯之后的執(zhí)行過程。

四、實踐案例一：counter 遞增

通過上面對 Compiler 渲染結果的理解，我們應該已經大概知道下面這段代碼最終會渲染成什么樣。我們目前要思考的問題就是，這個例子，編譯之后，收益表現在哪里？

function Index() {
  const [counter, setCounter] = useState(0)

  function __clickHanler() {
    console.log(counter)
    setCounter(counter + 1)
  }

  return (
    <div>
      <div id='tips'>基礎案例，state 遞增</div>
      <button onClick={__clickHanler}>counter++</button>
      <div className="counter">counter: {counter}</div>
    </div>
  )
}

一起來分析一下，當我們點擊按鈕時，此時 counter 增加，因此 __clickHanler 無法緩存，需要重新創(chuàng)建，那么 button 按鈕和 counter 標簽都無法緩存。

此時，只有 tips 元素可以被緩存。但是 tips 元素本身是一個基礎元素，在原本的邏輯中，經歷一個簡單的判斷就能知道不需要重新創(chuàng)建節(jié)點因此本案例的編譯之后收益非常有限。

編譯代碼結果如下：

function Index() {
  const $ = _c(10);

  const [counter, setCounter] = useState(0);
  let t0;

  if ($[0] !== counter) {
    t0 = function __clickHanler() {
      console.log(counter);
      setCounter(counter + 1);
    };

    $[0] = counter;
    $[1] = t0;
  } else {
    t0 = $[1];
  }

  const __clickHanler = t0;
  let t1;

  if ($[2] === Symbol.for("react.memo_cache_sentinel")) {
    t1 = <div id="tips">基礎案例，state 遞增</div>;
    $[2] = t1;
  } else {
    t1 = $[2];
  }

  let t2;

  if ($[3] !== __clickHanler) {
    t2 = <button onClick={__clickHanler}>counter++</button>;
    $[3] = __clickHanler;
    $[4] = t2;
  } else {
    t2 = $[4];
  }

  let t3;

  if ($[5] !== counter) {
    t3 = <div className="counter">counter: {counter}</div>;
    $[5] = counter;
    $[6] = t3;
  } else {
    t3 = $[6];
  }

  let t4;

  if ($[7] !== t2 || $[8] !== t3) {
    t4 = (
      <div>
        {t1}
        {t2}
        {t3}
      </div>
    );
    $[7] = t2;
    $[8] = t3;
    $[9] = t4;
  } else {
    t4 = $[9];
  }

  return t4;
}

五、實踐案例二：昂貴的子組件

在上面一個例子的基礎之上，我們新增一個子組件。該子組件的渲染非常耗時。

function Expensive() {
  var cur = performance.now()
  while (performance.now() - cur < 1000) {
    // block 1000ms
  }
  console.log('hellow')
  return (
    <div>我是一個耗時組件</div>
  )
}

父組件中引入該子組件，其他邏輯完全一致。

function Index() {
  const [counter, setCounter] = useState(0)

  function __clickHanler() {
    setCounter(counter + 1)
  }

  return (
    <div>
      <div id='tips'>基礎案例，state 遞增</div>
      <button notallow={__clickHanler}>counter++</button>
      <div className="counter">counter: {counter}</div>
+      <Expensive />
    </div>
  )
}

我們在之前「React 知命境」的學習中，對于性能優(yōu)化已經有非常深厚的積累。因此我們知道，在這種情況之下，由于父組件的狀態(tài)發(fā)生了變化，導致子組件 Expensive 會在 counter 遞增時重復執(zhí)行。從而導致頁面渲染時非常卡頓。

編譯之后，針對這一段邏輯的優(yōu)化代碼如下：

let t4;

if ($[7] === Symbol.for("react.memo_cache_sentinel")) {
  t4 = <Expensive />;
  $[7] = t4;
} else {
  t4 = $[7];
}

正如代碼所表達的一樣，由于這一個組件，并沒有依賴任何外部狀態(tài)，因此只需要在初始化時賦值一次即可。后續(xù)直接使用緩存值。

因此，在這個案例中，Compiler 編譯之后的優(yōu)化效果非常明顯，收益巨大。

六、實踐案例三：Tab 切換

這個案例會非常的復雜，經驗稍微欠缺一點的前端開發(fā)可能都實現不了。我們先來看一下我想要實現的演示效果。

從演示效果上來看，這是一個普通的 tab 切換。但是先別急，我還有要求。我希望能實現極限的性能優(yōu)化。

• 我希望首次渲染時，頁面渲染更少的內容，因此此時，只能先渲染默認的 Panel。其他 Panel 需要在點擊對應的按鈕時，才渲染出來。
• 在切換過程中，我希望能夠緩存已經渲染好的 Panel，只需要在樣式上做隱藏，而不需要在后續(xù)的交互中重復渲染內容
• 當四個頁面都渲染出來之后，再做切換時，此時只會有兩個頁面會發(fā)生變化，上一個選中的頁面與下一個選中的頁面。另外的頁面不參與交互，則不應該 re-render。

?

這個案例和要求不算特別難，但是對綜合能力的要求還是蠻高的，大家有空可以自己嘗試實現一下，看看能不能完全達到要求。

具體的完整實現我們會在后續(xù)的直播中跟大家分享。大家可以加我好友「icanmeetu」然后進 React19 討論群，React19 相關的直播消息會第一時間在群內公布。

這里，我主要想跟大家分享的就是 map 方法的小細節(jié)。有如下代碼：

{tabs.map((item, index) => {
  return (
    <item.component
      appearder={item.appeared}
      key={item.title}
      selected={current === index}
    />
  )
})}

它的編譯結果表現如下：

let t4;

if ($[7] !== current) {
  t4 = tabs.map((item_0, index_1) => (
    <item_0.component
      appearder={item_0.appeared}
      key={item_0.title}
      selected={current === index_1}
    />
  ));
  $[7] = current;
  $[8] = t4;
} else {
  t4 = $[8];
}

我們會發(fā)現，此時編譯緩存的是整個 map 表達式，但是由于 map 表達式又依賴于 current，因此，在我們點擊切換的交互過程中，每一次的 current 都會發(fā)生變化，那么這里針對 map 表達式的緩存就沒有了任何意義。

但是實際上，我們可以觀察到，我們有 4 個 Panel，點擊切換的交互發(fā)生時，實際上只有兩個 Pannel 發(fā)生了變化。因此，最極限的優(yōu)化是，只有這兩個組件對應的函數需要重新 re-render，那么我們的代碼應該怎么寫呢？

其實非常簡單，那就是不用 map，將數組拆開直接手寫，代碼如下：

let c1 = tabRef.current[0]
let c2 = tabRef.current[1]
let c3 = tabRef.current[2]
let c4 = tabRef.current[3]

<c1.component appearder={c1.appeared} selected={current === 0}/>
<c2.component appearder={c2.appeared} selected={current === 1}/>
<c3.component appearder={c3.appeared} selected={current === 2}/>
<c4.component appearder={c4.appeared} selected={current === 3}/>

然后，我們就會發(fā)現，在編譯結果中，不再緩存 map 表達式的結果，而是緩存每一個組件。

let t5;

if ($[7] !== c1.component || $[8] !== c1.appeared || $[9] !== t4) {
  t5 = <c1.component appearder={c1.appeared} selected={t4} />;
  $[7] = c1.component;
  $[8] = c1.appeared;
  $[9] = t4;
  $[10] = t5;
} else {
  t5 = $[10];
}

?

這樣做的收益在特定場景下的收益將會非常高。

七、強悍的性能：細粒度記憶化更新

經過上面的學習，想必各位道友對 React Compiler 的工作機制已經有了非常深刻的理解。此時，我們就需要分析一下，這樣的記憶化更新機制，到底有多強。

首先明確一點，和 Vue 等其他框架的依賴收集不同，React Compiler 依然不做依賴收集。

React 依然通過從根節(jié)點自上而下的 diff 來找出需要更新的節(jié)點。在這個過程中，我們會通過大量的判斷來決定使用緩存值。可以明確的是，Compiler 編譯之后的代碼，緩存命中的概率非常高，幾乎所有應該緩存的元素和函數都會被緩存起來。

因此，React Compiler 也能夠在不做依賴收集的情況下，做到元素級別的超級細粒度更細。但是，這樣做的代價就是，React 需要經歷大量的判斷來決定是否需要使用緩存結果。

所以這個時候，我們就需要明確，我所謂的大量判斷的時間成本，到底有多少？它會不會導致新的性能問題？

可以看到，Compiler 編譯之后的代碼中，幾乎所有的比較都是使用了全等比較，因此，我們可以寫一個例子來感知一下，超大量的全等比較到底需要花費多少時間。

測試代碼如下：

var cur = performance.now()

for(let i = 0; i < 1000000; i++) {
  'xxx' == 'xx'
}
var now = performance.now()
console.log(now - cur)

執(zhí)行結果，比較 100 萬次，只需要花費不到 1.3 毫秒。這太強了啊。我們很難有項目能夠達到 1000,000 次的比較級別，甚至許多達到 10000 都難。那也就意味著，這里大量的比較成本，落實到你的項目中，幾乎可以忽略不計。

為了對比具體的效果，我們可以判斷一下依賴收集的時間成本。

首先是使用數組來收集依賴。依然是 100 萬次收集，具體執(zhí)行結果如下。耗時 8 毫秒。

使用 Map 來收集依賴。100 萬次依賴收集耗時 54 ms。

使用 WeakMap 來收集依賴，那就更慢了。100萬次依賴收集耗時 200 毫秒。

?

WeakMap 的 key 不能是一個 number 類型。

數據展示給大家了，具體強不強，大家自行判斷。

?

這里我要明確的是，這樣的性能表現，在之前版本的項目中，合理運用 useCallback/memo 也能做到。只是由于對 React 底層默認命中規(guī)則不理解，導致大多數人不知道如何優(yōu)化到這種程度。React Compiler 極大的簡化了這個過程。

八、React Compiler 最佳實踐

有許多騷操作，React Compiler 并不支持，例如下面這種寫法。

{[1, 2, 3, 4, 5].map((counter) => {
  const [number, setNumber] = useState(0)
  return (
    <div key={`hello${counter}`} onClick={() => setNumber(number + 1)}>
      number: {number}
    </div>
  )
})}

這個操作騷歸騷，但是真的有大佬想要這樣寫。React 之前的版本依然不支持這種寫法。不過好消息是，React 19 支持了...

但是 React Compiler 并不支持。對于這些不支持的語法，React Compiler 的做法就是直接跳過不編譯，而直接沿用原組件寫法。

因此，React Compiler 的最佳實踐我總結了幾條

• 1、不再使用 useCallback、useMemo、Memo 等緩存函數
• 2、丟掉閉包的心智負擔，放心使用即可
• 3、引入嚴格模式
• 4、在你不熟悉的時候引入 eslint-plugin-react-compiler
• 5、當你熟練之后，棄用它，因為有的時候我們就是不想讓它編譯我們的組件
• 6、更多的使用 use 與 Action 來處理異步邏輯
• 7、盡可能少地使用 useEffect

這里，一個小小的彩蛋就是，當你不希望你的組件被 Compiler 編譯時，你只需要使用 var 來聲明狀態(tài)即可。因為這不符合它的語法規(guī)范

var [counter, setCounter] = useState(0)

而你改成 const/let，它就會又重新編譯該組件。可控性與自由度非常高。