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