React團隊最近都在忙啥呢？

大家好，我卡頌。

不知道大家有沒有一個感覺：React新特性的更新速度非常慢，時間通常是以年計。

實際上，在React漫長的發(fā)展過程中，除了很多優(yōu)秀的特性（比如Hooks、Suspense）外，還有很多最終沒有落地的想法。

這些想法通常不為開發(fā)者所知，這就帶來一些「React新特性進展緩慢」的誤解。

鑒于此，React官方博客[1]今天發(fā)布了一篇文章，介紹了團隊當前工作的方向。

本文讓我們來了解React接下來工作的重心，主要包括三方面的內(nèi)容：

底層特性

優(yōu)化相關

文檔相關

底層特性
進入React18后，「并發(fā)」一詞在React語境下被提及的頻率越來越高。

「并發(fā)」相關的改動對React影響也越來越大，甚至影響到日常開發(fā)（比如useEffect在嚴格模式下開發(fā)環(huán)境會執(zhí)行兩次）。

作為開發(fā)者，我們希望享受「并發(fā)」帶來的體驗提升，但不愿意接受業(yè)務代碼復雜度提高。

React團隊明白這個道理，所以React的發(fā)展模式主要是：

React團隊開發(fā)底層特性 + 與其他開源團隊合作開發(fā)上層特性

下面我們介紹兩個開發(fā)中的底層特性。

React Server Components
在20年的一篇官方博客中介紹了React Server Components[2]（后文簡稱為RSC）。作為底層特性，并不適合開發(fā)者直接使用。

React團隊與Vercel、Shopify合作，由這些團隊接入RSC，封裝到業(yè)務框架內(nèi)部（比如Next.js），再將框架提供給開發(fā)者使用。

這樣不僅能加強React與社區(qū)的聯(lián)系（由類似Vercel這樣的專業(yè)公司充當中介），又讓React團隊可以專心于React本身的迭代（而不用分心去開發(fā)React全家桶這樣的周邊庫）。

資源請求
很多外部資源請求（比如腳本、外部樣式、字體文件、圖片等）都有預加載的需求。

React團隊正在開發(fā)「React環(huán)境下通用的外部資源請求API」。

用該API請求的數(shù)據(jù)，請求過程中可以用Suspense fallback顯示「加載中的效果」，這樣可以防止視圖「爆爆米花」（popcorning）。

「爆爆米花」這個詞真是很形象，他形容「數(shù)據(jù)加載前后占據(jù)的高度不同，從而導致頁面尺寸劇烈變化」的現(xiàn)象。

想象頁面中有很多「待加載的圖片」，隨著圖片加載，頁面被圖片不斷撐開的樣子，就像玉米不斷膨脹成爆米花。

優(yōu)化相關
優(yōu)化相關進展主要體現(xiàn)在三個方面：

編譯時

運行時

分析工具

編譯時
黃玄[3]在React Conf 2021[4]介紹了React Forget，這是一個編譯器，用于為「可被優(yōu)化的React代碼」自動加上useMemo與useCallback。

該項目一直在不斷迭代，最近剛完成重寫。同時，編譯器的playground也在同步開發(fā)中。

運行時
React一直沒有實現(xiàn)Vue中的Keep Alive特性。當前，在React中控制組件顯隱只有兩個途徑：

mount/unmout組件。缺點是：組件卸載后保存在組件中的狀態(tài)就丟失了，保存在組件對應DOM中的狀態(tài)（比如滾動高度）也丟失了

用CSS（比如display: none）控制組件對應DOM顯隱。這樣雖然能保存狀態(tài)，但卻有性能問題 —— React在運行時還是會遍歷隱藏的組件（隱藏的組件還是會render）

Offscreen API的出現(xiàn)結合了兩者的優(yōu)點。

遵照開篇提到的「只關注底層特性」原則，開發(fā)者最好也不要直接使用Offscreen API，而是使用「集成了Offscreen的上層框架」（比如路由庫）。

插一句題外話，其實Offscreen API并不是一個全新的API。在源碼內(nèi)部，他是Suspense的組成部分之一。

接下來的迭代方向只是將其從源碼內(nèi)部暴露出來。

分析工具
分析組件性能一直是剛需，為此React團隊開發(fā)了瀏覽器分析工具：



隨著React18的到來，會再新增一種時間線分析工具（timeline profiler）用于分析「并發(fā)更新時的調(diào)度情況」。

但是，他們都沒有很好解決以下需求：

某一次更新比較緩慢，該怎么分析？

某次交互的完整過程（比如一次點擊，一次頁面導航），該如何分析性能？

當前正在開發(fā)一個API用于分析這些具體情況下的性能問題。

文檔相關
React新文檔當前仍處于Beta版本，內(nèi)容還不完全。

但React團隊對待新文檔的態(tài)度，絕對是認真的，有個很有意思的細節(jié)：

在總結useEffect應用場景時，Dan發(fā)現(xiàn)一些常見場景可以用一個新的原生Hook來應對。

于是，文檔寫了一半，Dan又跑去提出了useEvent提案[5]。

雖然當前文檔還沒完成，但從已公布的內(nèi)容來看，不管是React萌新還是老手，都能從新文檔中有所收獲。

總結
在21年的React圣誕特輯一起走進React核心團隊[6]一文中，作者表達了一個觀點：

對于像Hooks這樣的完善特性，能夠成為Release，在其背后還有許許多多特性甚至沒到達RFC階段。

所有特性都必須等到完全準備就緒為止。在此之前，只能給其他特性讓路。

在一個如此重視交付，并且交付的速度越來越快的行業(yè)，當你的承諾無法兌現(xiàn)時，這讓人非常沮喪。但這并不意味著沒有進步：

你有時間思考與計劃，有時間實驗與學習。即使暫時失敗了，也會為成功的特性帶來啟發(fā)。

即使你還沒完成年初的預期工作，也要相信挫折和顛覆是常態(tài)，而不是例外，無論好壞，即使在React團隊也是如此。

不能因為你沒有新的特性產(chǎn)出，就意味著你沒有提供價值。

我想，這也是React團隊公布接下來工作方向的一個原因吧。

參考資料
[1]
React官方博客:
https://reactjs.org/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022.html

[2]
React Server Components:
https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html

[3]
黃玄:
https://twitter.com/Huxpro

[4]
React Conf 2021:
https://www.youtube.com/watch?v=lGEMwh32soc

[5]
useEvent提案:
https://github.com/reactjs/rfcs/pull/220

[6]
一起走進React核心團隊:
https://react.christmas/2020/24

作者：卡頌


歡迎關注微信公眾號 ：魔術師卡頌