2161 天！

這是 React 團(tuán)隊(duì)從計(jì)劃為 React 增加 并發(fā)渲染 的能力，到 React 18 可用版本發(fā)布所花費(fèi)的時(shí)間。

為啥中間花費(fèi)了這么長的時(shí)間？中間又發(fā)生了哪些有趣的故事？我們回到 2016 年，來回顧一下 React 并發(fā)渲染誕生的過程！

今天這篇文章會(huì)以更輕松的方式帶大家看整體的演進(jìn)之路，不會(huì)涉及太多的技術(shù)性，讀起來會(huì)更簡單，相信看完這篇文章再去看之前的問會(huì)有不一樣的理解。

瀏覽器的瓶頸

早在 2016 年，React 就已經(jīng)開始在前端屆爆火了。React 團(tuán)隊(duì)始終有一個(gè)目標(biāo)，就是給基于 React 而構(gòu)建的上百萬個(gè)網(wǎng)站提供最好的性能體驗(yàn)！

但是提升性能最大的瓶頸，不一定和 React 本身有關(guān)。而是與 React 建立在的語言 JavaScript，以及 JavaScript 所在的瀏覽器環(huán)境有關(guān)。

瀏覽器會(huì)在一個(gè)主線程里處理所有的 JavaScript 代碼、用戶事件、渲染、布局、繪制以及重排。

通常情況下，它們互不打擾，相互運(yùn)行的挺和諧的，但是如果一不小心，就有可能導(dǎo)致問題。

React Conf 2018

React 現(xiàn)在是同步的，這意味著當(dāng)你更新組件時(shí)，React 會(huì)同步處理這個(gè)更新， 它會(huì)在一個(gè)主線程上持續(xù)工作，直到所有更新完成。所以問題在于，用戶事件也會(huì)在主線程上觸發(fā)，如果此時(shí) React 正在渲染更新，同時(shí)用戶嘗試以同步的方式輸入一些內(nèi)容， React 會(huì)等待正在執(zhí)行的所有渲染完成后才能去處理用戶事件。

— React Conf 2018

Fiber 誕生

多線程渲染

所以，如果問題在于渲染阻塞了主線程，那我們不能在另外一個(gè)線程里去完成渲染工作嗎？比如使用 webworker？

但實(shí)際上這并不是 React 想要的， React 想要的是一種讓當(dāng)前的渲染工作變得更靈活的方案。

React Cong 2017

我們有一些 IO 的工作，然后是一些 CPU 的工作，在理想狀況下，我們應(yīng)該能夠并行執(zhí)行其中一些工作了。這不是一個(gè)性能問題，這基本上是一個(gè)調(diào)度問題了。

— React Cong 2017

React 團(tuán)隊(duì)發(fā)現(xiàn)，他們可以通過某種方式來優(yōu)化 React，以便可以區(qū)分低優(yōu)先級(jí)和高優(yōu)先級(jí)的工作。

例如，用戶輸入和動(dòng)畫渲染屬于高優(yōu)先級(jí)任務(wù)，他們可以讓 React 擁有在這些任務(wù)之前互相切換的能力。

理論上，通過這種方式，每個(gè) React 應(yīng)用的體驗(yàn)都可以得到提升，因?yàn)?React 總是最優(yōu)先考慮最重要的工作。

這就是 React 團(tuán)隊(duì)這段時(shí)間做的事情，他們將其命名為 React Fiber。

Fiber 并沒有被作為一個(gè)新的框架，而是作為一個(gè)主要的 React 版本：React 16 推出來了。

它讓 React 具有了異步可中斷的能力。

異步渲染

2017 年初，React 現(xiàn)在看起來更聰明一點(diǎn)了，它能夠優(yōu)先處理一些工作，并且能中斷當(dāng)前渲染。

但是，這個(gè)能力只能說是個(gè)半成品，另外還有一個(gè)非常困難的事情是找到一個(gè)公共 API，讓 React 開發(fā)者以一種不會(huì)完全破壞當(dāng)前 React 生態(tài)的方式使用這些能力。

解決這個(gè)問題的第一部分，是擺脫掉可能會(huì)對(duì)新的異步可中斷渲染的能力起到副作用的部分。

在新的架構(gòu)中，一個(gè)組件的渲染被分為兩個(gè)階段：第一個(gè)階段(也叫做 render 階段)是可以被 React 打斷的，一旦被打斷，這階段所做的所有事情都被廢棄，當(dāng) React 處理完緊急的事情回來，依然會(huì)重新渲染這個(gè)組件，這時(shí)候第一階段的工作會(huì)重做一遍。兩個(gè)階段的分界點(diǎn)，就是 render 函數(shù)。render 函數(shù)之前的所有生命周期函數(shù)(包括 render )都屬于第一階段。

React 16.3

如果我們?cè)谶@些生命中期中引入了副作用，被重復(fù)執(zhí)行，就可能會(huì)給我們的程序帶來不可預(yù)知的問題，所以到了 React v16.3，React 干脆引入了一個(gè)新的生命周期函數(shù) getDerivedStateFromProps，這個(gè)生命周期是一個(gè) 靜態(tài)方法，在里面根本不能通過 this 訪問到當(dāng)前組件，輸入只能通過參數(shù)，對(duì)組件渲染的影響只能通過返回值。

同時(shí)，React 團(tuán)隊(duì)開始將這種新的模式稱為 — async rending。

React Conf 2018

這里最大的問題不是性能，而是調(diào)度，所以我們必須考慮調(diào)度，所以我們稱這些新的能力為 async rending。我們的目標(biāo)是可以讓程序開發(fā)者適應(yīng)設(shè)備和網(wǎng)速等用戶限制，讓交互體驗(yàn)變得更好。

— React Conf 2018

Hooks

然而，一年后，dan 繼續(xù)表示：React 缺少了一些讓調(diào)度工作更簡單的東西，這就是 Hooks。

Hooks 于 2018 年十月在 React comp 中發(fā)布，它是 React 自發(fā)布以來最大的變化。

Hooks 最初的重點(diǎn)在于它可以讓你用函數(shù)式寫法替代類來創(chuàng)建 React 組件。

但實(shí)際上它們帶來的收益要更多，你可以更好的進(jìn)行代碼復(fù)用、組合、設(shè)置默認(rèn)值，另外還有比較重要的一點(diǎn)，Hooks 可以更自然的編寫出和異步渲染更兼容的代碼。

concurrent React

然后在這個(gè)階段我們還解鎖了一個(gè)新名字：concurrent React。

React Conf 2018

async 是一個(gè)非常廣泛的術(shù)語，它可以描述很多內(nèi)容，我們認(rèn)為 concurrent React 這個(gè)詞更恰當(dāng)一點(diǎn)。 concurrent React 可以同時(shí)處理多個(gè)任務(wù)，并且根據(jù)這些任務(wù)的優(yōu)先級(jí)在它們之間切換；它可以讓渲染樹進(jìn)行部分渲染，而不將最終結(jié)果提交給 DOM；并且，最重要的， concurrent React 不會(huì)阻塞主線程。

— React Conf 2018

concurrent mode

然而，這種說法并沒有持續(xù)多久，很快它就會(huì) concurrent mode 替代了。

事件來到了 2019 年，我們終于得到了一些可以拿出來用的東西，concurrent React 正式更名為 concurrent mode 。

React Conf 2019

concurrent mode 讓 React 應(yīng)用程序可以中斷較大的低優(yōu)先級(jí)任務(wù)，以專注于更高優(yōu)先級(jí)的事情(例如響應(yīng)用戶輸入事件)。

— React Conf 2019

concurrent mode 現(xiàn)在已經(jīng)可以在實(shí)驗(yàn)?zāi)Ｊ较率褂昧?— React Conf 2019

不容易，搞了三年了，用戶終于有一些可以使用的東西了。。。

但是，它是最終版本的 API 嗎？不是！它已經(jīng)可以在生產(chǎn)環(huán)境使用了嗎？不能！

但是，concurrent mode 讓我們終于可以在程序里面去體驗(yàn)一下了，我們可以在實(shí)驗(yàn)?zāi)Ｊ较麻_啟，這樣我們就可以看到并發(fā)渲染的性能優(yōu)勢(shì)了。

但是，實(shí)際上，想法很美好，我們?nèi)匀皇艿搅松?jí)策略的限制。

升級(jí)策略

React 在以前是不可以多版本共存的，這意味著我們只能在一些 DEMO 項(xiàng)目和新項(xiàng)目中看到這種提升，如果我們想在已經(jīng)存在的大型應(yīng)用程序里面去用，就需要一個(gè)更好的升級(jí)策略。

React 17 就是用來解決這個(gè)問題的，它在一年后的 2020 年 8 月發(fā)布。

React 17 允許我們?cè)谕粋€(gè)應(yīng)用程序里允許多個(gè)版本的 React，這讓我們可以在大型項(xiàng)目里采用增量升級(jí)策略，你可以將程序的部分升級(jí)到 React 18。

然而，它實(shí)際起到的作用也沒有那么好，因?yàn)闈u進(jìn)式的升級(jí)策略也無法做到更精細(xì)的控制。

React 團(tuán)隊(duì)還另外提供了一種稱之為 blocking mode 的模式，是處于舊的模式和新的并發(fā)渲染模式之間的混合模式。

怎么說呢?也是個(gè)弱雞的策略，沒有達(dá)到預(yù)想的效果，React 團(tuán)隊(duì)在后續(xù)的一段時(shí)間收到了大量的用戶反饋。

concurrent features

這時(shí)，距離 React 宣布新的架構(gòu)開始，已經(jīng)過去了 5 年的時(shí)間，在收到了大量的反饋后，React 團(tuán)隊(duì)又做出了改變，這次，似乎來到這最終的解決方案？

React Conf 2021

在聆聽了大量的用戶反饋后，我們很高興的分享 — concurrent mode 在 React 18 中消失掉了，它被逐步采用的漸進(jìn)式策略取代，你可以按照自己的節(jié)奏采用并發(fā)渲染。

— React Conf 2021

concurrent features — 這個(gè)名字很明顯，因?yàn)闊o法做到直接全面升級(jí)并發(fā)渲染，React 希望提供給我們一些特性讓我們?nèi)ミx擇性的啟用并發(fā)渲染。

在這種模式下，你可以讓程序特定的部分啟用并發(fā)渲染。

useDeferredValue

我們需要通過一些 api，讓我們?cè)谡麄€(gè)渲染過程中確定工作的優(yōu)先級(jí)，擁有可中斷的能力， 首先我們來看看 useDeferredValue ，它可以讓我們?nèi)?biāo)記某個(gè)具體狀態(tài)的優(yōu)先級(jí)。

比如我們現(xiàn)在有這樣的場(chǎng)景，用戶輸入了一些搜索關(guān)鍵字后，我們需要將搜索到的數(shù)據(jù)渲染到下面的詳情里，如果這個(gè)處理比較耗時(shí)，那么連續(xù)的用戶輸入會(huì)有卡頓的感覺。實(shí)際上，我們希望的是用戶的輸入能得到快速的響應(yīng)，但是下面詳情的渲染多等待一會(huì)其實(shí)無所謂。

這時(shí)，我們可以通過 useDeferredValue 創(chuàng)建一個(gè) deferredText，真正的意思是 deferredText 的渲染被標(biāo)記為了低優(yōu)先級(jí)，用戶輸入已經(jīng)不會(huì)有卡頓的感覺了。

startTransition

useDeferredValue 是讓我們標(biāo)記哪些具體的狀態(tài)擁有更低的優(yōu)先級(jí)，而 startTransition 可以明確的告訴 React 哪些更新具有更低的優(yōu)先級(jí)。

當(dāng)有一些更新被包裹在 startTransition 下時(shí)，React 將已較低的優(yōu)先級(jí)去處理這些更新，從而優(yōu)先去處理像用戶輸入這樣更高優(yōu)先級(jí)的更新。

Suspense

另外你可能還會(huì)經(jīng)常聽到的一個(gè)詞是 Suspense，它的目標(biāo)是讓我們?cè)?React 組件中讀取遠(yuǎn)程數(shù)據(jù)像使用 props 和 state 這樣簡單。

是一個(gè) React 組件，如果組件樹有一些位置還沒準(zhǔn)備好，它可以讓你以聲明的方式控制這部分渲染的 UI。

它可以讓我們將左側(cè)這樣代碼簡化成右側(cè)這樣，讓你可以在 React 組件中以同步代碼的寫法編寫異步代碼。

React 18 是最終版本嗎

React 官方在官網(wǎng)中提到，大多數(shù)情況下我們都不會(huì)和這些并發(fā)渲染的 API 直接交互，這讓我們很難判斷 React 18 究竟是不是一個(gè)革命性的版本。

不管怎么說，它是一個(gè)歷時(shí)兩千多天的、我們期待已久的巨大里程碑。

你認(rèn)為它是 React 并發(fā)渲染的最終版本嗎？