React的操作系統(tǒng)夢(mèng)，任重道遠(yuǎn)
這篇文章包括如下內(nèi)容：
簡(jiǎn)要回顧下React從16～21年的迭代歷程
React為什么對(duì)新特性(Concurrent Mode)有這么大執(zhí)念
為什么當(dāng)前社區(qū)項(xiàng)目/庫(kù)要升級(jí)到Concurrent Mode比較困難
迭代歷程回顧
React Core Team從16年開(kāi)始改造React的核心模塊Reconciler(diff算法會(huì)在該模塊執(zhí)行)。
經(jīng)過(guò)一年多的改造，將其從流程不可中斷的「遞歸實(shí)現(xiàn)」(被稱為Stack Reconciler)改為流程可中斷的「遍歷實(shí)現(xiàn)」(被稱為Fiber Reconciler)。
在此之后，基于Fiber Reconciler，實(shí)現(xiàn)了一套可以區(qū)分任務(wù)優(yōu)先級(jí)的機(jī)制，大體原理如下：
不同交互(用戶點(diǎn)擊交互/請(qǐng)求數(shù)據(jù)/用戶拖拽...)觸發(fā)的狀態(tài)更新(比如調(diào)用this.setState)會(huì)擁有不同優(yōu)先級(jí)，在源碼內(nèi)對(duì)應(yīng)一個(gè)時(shí)間戳變量expirationTime。
React會(huì)根據(jù)expirationTime的大小調(diào)度這些更新，最終實(shí)現(xiàn)的效果為：「用戶交互」觸發(fā)的更新會(huì)擁有更高的優(yōu)先級(jí)，先于「請(qǐng)求數(shù)據(jù)」觸發(fā)的更新。
高優(yōu)先級(jí)意味著該更新對(duì)DOM產(chǎn)生的影響會(huì)更快呈現(xiàn)在用戶面前。
在此之后，React Core Team發(fā)現(xiàn)基于expirationTime的調(diào)度算法雖然能滿足fiber樹(shù)的整體優(yōu)先級(jí)調(diào)度，但是不夠靈活(比如無(wú)法滿足局部fiber樹(shù)的優(yōu)先級(jí)調(diào)度(例如Suspense))。
具體原因見(jiàn)這篇文章：?jiǎn)l(fā)式更新算法
所以去年React Core Team的Andrew Clark將expirationTime模型重構(gòu)為以一個(gè)32位二進(jìn)制的位代表優(yōu)先級(jí)的lane模型。
PR參見(jiàn)Initial Lanes implementation #18796[1]
如果你是個(gè)React重度用戶，讓你聊聊這些年React的重大變化，可能你會(huì)說(shuō)：
- Context API重構(gòu)
- Hooks
但從我們上面講到的內(nèi)容來(lái)看，從16年到21年，React底層其實(shí)做了大量重構(gòu)工作。
有人問(wèn)：做了這么多重構(gòu)，React開(kāi)發(fā)者居然一點(diǎn)感知都沒(méi)有?
是的，即使當(dāng)前穩(wěn)定版本的React底層已經(jīng)支持時(shí)間切片、支持更智能的更新合并機(jī)制(batchedUpdates)。
但是React內(nèi)部有很多裹腳布一樣的代碼讓新架構(gòu)的行為表現(xiàn)的與老架構(gòu)(Stack Reconciler)一致。
React Core Team的執(zhí)念
就像開(kāi)發(fā)業(yè)務(wù)的開(kāi)發(fā)者需要背負(fù)OKR，強(qiáng)如React Core Team成員，也會(huì)為OKR苦惱。
20年的React圣誕特輯，React Core team的Rachel Nabors小姐姐就在文章Inside the React Core team[2]中表示：
不能因?yàn)槟銢](méi)有產(chǎn)出就代表你沒(méi)有價(jià)值(一把辛酸淚)。
作為視圖層的庫(kù)，在不開(kāi)大腦洞的情況下，React能做的已經(jīng)趨于極致了。
協(xié)程、并發(fā)這些操作系統(tǒng)中的概念被搬進(jìn)React，函數(shù)式編程的理念也在React中落地(Hooks)。
React該何去何從?
React的靈魂人物、Hooks的作者、同時(shí)也是TC39成員Sebastian Markbåge給出的答案是：
向后、向BFF層發(fā)展
簡(jiǎn)單的說(shuō)：
在SSR領(lǐng)域，當(dāng)前的實(shí)現(xiàn)方案還比較粗獷：
- 組件在服務(wù)端編譯成模版字符串(脫水)
- 前端渲染模版字符串
- 完成組件的可交互(注水)與余下的渲染
這樣的SSR方案粒度不夠細(xì)，如果Fiber Reconciler能將時(shí)間切片的粒度控制在組件級(jí)別，SSR的粒度為什么不能控制在組件級(jí)別呢?
要達(dá)到這個(gè)目標(biāo)，起碼需要支持：
- 一套R(shí)eact組件的流式數(shù)據(jù)傳輸協(xié)議(區(qū)別于字符串模版)
- 前端能精確控制組件的狀態(tài)(加載中/加載失敗/加載成功)，即Suspense特性
而Suspense特性依賴Concurrent Mode的時(shí)間切片特性。
沒(méi)有社區(qū)的大量庫(kù)接入Concurrent Mode，使時(shí)間切片成為默認(rèn)配置，Sebastian Markbåge的遠(yuǎn)大理想(OKR)無(wú)異于空中樓閣。
所以，當(dāng)務(wù)之急是讓社區(qū)盡快跟上React升級(jí)的步伐。
升級(jí)Concurrent Mode的難點(diǎn)
當(dāng)前社區(qū)大量React生態(tài)庫(kù)的邏輯都是基于如下React運(yùn)行流程：
- 狀態(tài)更新 --> render --> 視圖渲染
如果React的運(yùn)行流程變?yōu)椋?/p>
- 狀態(tài)更新 --> render（可暫停） --> 視圖渲染
- 或
- 狀態(tài)更新 --> render（中斷）--> 重新?tīng)顟B(tài)更新 --> render（可暫停） --> 視圖渲染
會(huì)發(fā)生什么?
會(huì)發(fā)生一種被稱為tearing的現(xiàn)象，我們來(lái)舉個(gè)例子：
假設(shè)我們有一個(gè)變量externalSource，初始值為1。
1000ms后externalSource會(huì)變?yōu)?。
- let externalSource = 1;
- setTimeout(() => {
- externalSource = 2;
- }, 1000)
我們有個(gè)組件A，他渲染的DOM依賴于externalSource的值：
- function A() {
- return <p>{externalSource}</p>;
- }
在當(dāng)前版本的React中，在我們的應(yīng)用中組件樹(shù)的不同地方使用A組件，會(huì)出現(xiàn)某些地方的DOM是<p>1</p>，某些地方是<p>2</p>么?
答案是：不會(huì)。
因?yàn)楫?dāng)前React的如下運(yùn)行流程是同步的：
- 狀態(tài)更新 --> render --> 視圖渲染
使externalSource變?yōu)?的setTimeout會(huì)在這個(gè)流程對(duì)應(yīng)的task(宏認(rèn)為)執(zhí)行完后再執(zhí)行。
但是當(dāng)切換到Concurrent Mode：
- 狀態(tài)更新 --> render（可暫停） --> 視圖渲染
當(dāng)render暫停時(shí)，瀏覽器獲得JS線程控制權(quán)，就會(huì)執(zhí)行使externalSource變?yōu)?的setTimeout。
這樣可能不同的A組件渲染出的p標(biāo)簽內(nèi)的數(shù)字不一樣。
這種由于React運(yùn)行流程變化，導(dǎo)致依賴外部資源時(shí)，狀態(tài)與視圖不一致的現(xiàn)象，就是tearing。
這里改變externalSource的外力，可能來(lái)自于各種task(IO、setTimeout...)
- 當(dāng)前有個(gè)解決外部資源狀態(tài)同步的提案useMutableSource[3]
- 這個(gè)庫(kù)will-this-react-global-state-work-in-concurrent-mode[4]測(cè)試了主流狀態(tài)管理庫(kù)是否會(huì)導(dǎo)致tearing
艱難的小步前進(jìn)
為了讓開(kāi)發(fā)者能漸進(jìn)、少點(diǎn)痛苦的升級(jí)到Concurrent Mode，React Core Team一直在努力：
- 提供StrictMode(嚴(yán)格模式)組件，規(guī)范開(kāi)發(fā)者行為
- 將componentWilXXX標(biāo)記為unsaft_
- 提供漸進(jìn)的升級(jí)路線，(從legacy模式到blocking模式到concurrent模式)
顯然，React Core Team覺(jué)得社區(qū)的升級(jí)速度還是太慢了。
最近，一個(gè)新的PR被合入：Make time-slicing opt-in[5]
這個(gè)PR中提到：在下個(gè)主版本中，會(huì)全量Concurrent Mode，但是這個(gè)Concurrent Mode會(huì)默認(rèn)關(guān)閉時(shí)間切片功能。
就差直接喊話開(kāi)發(fā)者：各位大爺們，求求你們快升級(jí)吧，OKR就指著他了😭
這種悲傷、殷切、又期待的心情直接導(dǎo)致了提交這次PR的Ricky小哥逐漸沙雕(狗頭保命)：
React的操作系統(tǒng)夢(mèng)，任重而道遠(yuǎn)啊～～～
參考資料
[1]Initial Lanes implementation #18796:
https://github.com/facebook/react/pull/18796
[2]Inside the React Core team:
https://react.christmas/2020/24
[3]useMutableSource:
https://github.com/reactjs/rfcs/blob/master/text/0147-use-mutable-source.md
[4]will-this-react-global-state-work-in-concurrent-mode:
https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-mode
[5]Make time-slicing opt-in:
https://github.com/facebook/react/pull/21072
