出品 | 51CTO技術(shù)棧（微信號(hào)：blog51cto）

React的一個(gè)改動(dòng)細(xì)節(jié)引起了前端圈的聲討。

“這項(xiàng)改動(dòng)違背了React的第一設(shè)計(jì)原則！”

“這會(huì)顯著降低使用React框架的網(wǎng)站的性能?！?/p>

“這是一個(gè)令人惱火、無法理解的改動(dòng)！”

提起React，作為世界上最受歡迎和使用最多的UI框架，許多網(wǎng)絡(luò)“大牌”都有它的身影：不用提新潮一代的Netflix、Airbnb、Discord 等，僅誕生地Meta（Facebook、Instagram 和 Whatsapp）就已經(jīng)足夠讓其揚(yáng)名天下。

考慮到 React 用于創(chuàng)建數(shù)十億人使用的用戶界面，這樣說也不為過：互聯(lián)網(wǎng)流量的很大一部分是由 React “處理”的。

一、一場(chǎng)討論讓React官方暫停了項(xiàng)目

這里的主要話題，正在討論的變化正是React19版本。

隨著React 19全新功能和 DX 改進(jìn)，處理并行fetching問題的方式發(fā)生了變化：禁用了同一 Suspense 邊界內(nèi)兄弟節(jié)點(diǎn)的并行渲染。這實(shí)質(zhì)上為在這些兄弟節(jié)點(diǎn)內(nèi)部獲取的數(shù)據(jù)引入了數(shù)據(jù)獲取瀑布。

這個(gè)小變化起初并沒有引起人們注意，卻被被一位細(xì)心的前端大牛Dominik發(fā)現(xiàn)了發(fā)到海外社交媒體上，并表示這可能會(huì)顯著降低許多依賴 React 的網(wǎng)站的性能，一時(shí)間引起了網(wǎng)友們的鼎沸討論。

一切都從Dominik發(fā)的這條推文開始：

圖片

帖子中指出：React19查詢現(xiàn)在是以瀑布形式運(yùn)行。

現(xiàn)在，對(duì)于那些不認(rèn)識(shí) Dominik（又名TkDodo）的人來說，他與傳奇的Tanner Linsley一起是廣泛使用的TanStack Query的核心維護(hù)者之一。

一切都從這條推文開始：

圖片

Dominik（又名TkDodo）何許人？他與傳奇的Tanner Linsley一起是廣泛使用的TanStack Query的核心維護(hù)者之一。

帖子中指出：React19在Suspense處理并行fetching的方式跟React18不一樣了？查詢現(xiàn)在是以瀑布形式運(yùn)行。

隨后引起了連鎖反應(yīng)：

1.“這是一個(gè)令人惱火，不可理解的改動(dòng)！不僅客戶端組件中也變動(dòng)了，甚至RSC中的并行fetch也變了。這對(duì)react-query而言是一場(chǎng)災(zāi)難。”

圖片

2.“可想而知，這也會(huì)影響lazily加載的組件（react.lazy）！”

圖片

3.我能理解Dominik的痛苦：這難道不違背React第一設(shè)計(jì)原則：compositon嗎？如果我理解正確的話，現(xiàn)在你無法再使用復(fù)雜的預(yù)取技巧來編寫數(shù)據(jù)需求。或者你必須將所有數(shù)據(jù)提取提升到公共父級(jí)。

圖片

此次React 19禁用了同一 Suspense 邊界內(nèi)兄弟節(jié)點(diǎn)的并行渲染，這實(shí)質(zhì)上為在這些兄弟節(jié)點(diǎn)內(nèi)部獲取的數(shù)據(jù)引入了數(shù)據(jù)獲取瀑布。

以下是此類事情的一個(gè)例子：

圖片

https://github.com/facebook/react/pull/26380#issuecomment-2166178673

所有這一切中最糟糕的是，除了性能會(huì)有嚴(yán)重下降，而且還將影響很多依賴這種模式的人，但只有一行項(xiàng)目符號(hào)毫不客氣地提到了這一變化。

很多人也許納悶：究竟是怎么回事？下面我們就細(xì)細(xì)道來。

二、懸疑回顧

為了理解這到底是什么，我們首先需要快速回顧一下 React 的 Suspense。

Suspense 是一個(gè) React 組件，它允許您顯示一個(gè)回退，直到其子組件完成加載，要么是因?yàn)檫@些子組件是延遲加載的，要么是因?yàn)樗鼈冋谑褂脝⒂?Suspense 的數(shù)據(jù)獲取機(jī)制。

使用方式如下：

<Suspense fallback={<Loading />}>
  <ComponentThatFetchesDataOrIsLazyLoaded />
</Suspense>

盡管 Suspense 已經(jīng)成為 React API 的一部分很長(zhǎng)一段時(shí)間了，但是在很長(zhǎng)一段時(shí)間內(nèi)，它的唯一官方批準(zhǔn)用途是使用來延遲加載組件React.lazy，這對(duì)于對(duì)應(yīng)用程序進(jìn)行代碼分割并僅在需要時(shí)加載分割的部分非常有用。

當(dāng)與 一起使用時(shí)，當(dāng)?shù)谝淮螄L試渲染延遲加載的組件時(shí)（即，在延遲加載之前），它會(huì)觸發(fā) Suspense 邊界（即包裝組件）并渲染回退，直到獲取組件的代碼完成，然后它會(huì)渲染組件React.lazySuspense本身。

長(zhǎng)期以來，我們一直被承諾在客戶端上為 Suspense 提供官方數(shù)據(jù)提取支持（使用 RSC 時(shí)，它已經(jīng)在服務(wù)器上運(yùn)行），但直到現(xiàn)在我們才真正實(shí)現(xiàn)它，盡管如此，許多庫（TanStack Query 就是其中之一）已經(jīng)通過研究 React 的內(nèi)部結(jié)構(gòu)實(shí)現(xiàn)了它。正因?yàn)槿绱?，目前生產(chǎn)中有許多應(yīng)用程序確實(shí)使用Suspense在客戶端上進(jìn)行數(shù)據(jù)提取。

三、性能變慢了？

從現(xiàn)在起（React 18.3.1），當(dāng)在同一個(gè) Suspense 邊界內(nèi)使用啟用 Suspense 的數(shù)據(jù)獲取或延遲加載多個(gè)組件時(shí)，React 會(huì)在退出渲染之前嘗試渲染所有兄弟組件，即使第一個(gè)兄弟組件已暫停。

實(shí)際上，這意味著這些兄弟節(jié)點(diǎn)中發(fā)生的數(shù)據(jù)獲取或延遲加載將全部并行啟動(dòng)。

下面是一個(gè)展示這個(gè)想法的例子：

function App() {
  return (
    <>
      <Suspense fallback={"Loading..."}>
        <ComponentThatFetchesData val={1} />
        <ComponentThatFetchesData val={2} />
        <ComponentThatFetchesData val={3} />
      </Suspense>
    </>
  );
}


const ComponentThatFetchesData = ({ val }) => {
  const result = fetchSomethingSuspense(val);


  return <div>{result}</div>;
};

圖片

演示地址：https://stackblitz.com/edit/vitejs-vite-x3nv7r?file=src%2FApp.jsx

在這個(gè)例子中（在 React 18 中），即使fetchSomethingSuspense導(dǎo)致第一個(gè)ComponentThatFetchesData暫停，React 仍然會(huì)嘗試渲染它的兄弟，這將觸發(fā)每個(gè)兄弟的并行數(shù)據(jù)獲取。

通過查看每次觸發(fā)數(shù)據(jù)提取時(shí)記錄的控制臺(tái)，可以看出：所有數(shù)據(jù)獲取幾乎同時(shí)開始。

現(xiàn)在讓我們看看當(dāng)我們?cè)?React 19（canary）中運(yùn)行完全相同的代碼時(shí)會(huì)發(fā)生什么：

圖片

演示地址：https://stackblitz.com/edit/vitejs-vite-55rddj?file=src%2FApp.jsx

當(dāng)我們?cè)俅尾榭纯刂婆_(tái)時(shí)，我們注意到現(xiàn)在有一個(gè)瀑布，因?yàn)槊總€(gè)數(shù)據(jù)提取僅在前一個(gè)數(shù)據(jù)完成后才啟動(dòng)。

發(fā)生這種情況是因?yàn)橐韵?PR：

圖片

在該 PR 引入更改之后，React 不會(huì)嘗試渲染同一 Suspense 邊界內(nèi)的所有兄弟組件，而是會(huì)在第一個(gè)掛起的組件上放棄，在這種情況下，您會(huì)首先嘗試渲染第一個(gè)組件，然后它會(huì)掛起，然后只有在其數(shù)據(jù)獲取完成并且您可以渲染它之后，您才會(huì)到達(dá)下一個(gè)兄弟組件，它將再次掛起，依此類推每個(gè)兄弟組件。

此外，這種新行為不僅會(huì)影響使用 Suspense 進(jìn)行數(shù)據(jù)提取的使用，還會(huì)影響使用React.lazy，因?yàn)檫@是一種舊模式，所以得到了官方支持并且更加廣泛。

圖片

四、背后是什么鬼

這一變化背后的理由（在前面提到的 PR 中寫明）是，在實(shí)際暫停之前嘗試渲染所有兄弟節(jié)點(diǎn)元素消耗，并且會(huì)延遲顯示回退。

此外，這一變化與React 團(tuán)隊(duì)自 React 18 之前引入 Suspense 以來一直在推動(dòng)的“獲取時(shí)渲染”方法相輔相成。

理想情況下，我們不應(yīng)該在使用它的同一組件的渲染上啟動(dòng)數(shù)據(jù)提取，而應(yīng)該將其提升并盡早開始提取數(shù)據(jù)。

雖然從性能角度來看這無疑是最好的方法，但它確實(shí)帶來了顯著的 DX 缺陷，因?yàn)闊o法共置組件及其數(shù)據(jù)要求。

這里不會(huì)深入討論這個(gè)話題，因?yàn)橐呀?jīng)有很多人討論了它，甚至有一個(gè)專門為解決這個(gè)問題而創(chuàng)建的庫，但這里推薦某條特定觀點(diǎn)的推文：

這里的主要內(nèi)容是，如果不使用編譯器，就不可能同時(shí)擁有最佳的性能特性以及組件及其數(shù)據(jù)需求的搭配，而這正是 Relay 所做的。

五、結(jié)局還算圓滿

幸運(yùn)的是，這個(gè)故事有一個(gè)圓滿的結(jié)局。在經(jīng)歷了大量公眾反對(duì)、激烈討論以及幕后爭(zhēng)論之后，React 團(tuán)隊(duì)最終決定暫時(shí)推遲這一改變。

圖片

這并不是社區(qū)第一次反對(duì)在不考慮 React 在 Meta 和 Vercel 之外的使用方式的情況下引入的更改。React 團(tuán)隊(duì)（尤其是 Vercel）推動(dòng)將 RSC 成為使用 React 構(gòu)建的基本組成部分就是一個(gè)例子。

很明顯，React 維護(hù)者和社區(qū)對(duì)于 React 的未來前景的看法存在分歧。這些問題溝通會(huì)有哪些進(jìn)展？后續(xù)還有待觀察。