大家好，我卡頌。

2022年3月29號，React18正式版發(fā)布。

從v16開始，React團(tuán)隊就在普及并發(fā)的概念。在v18的迭代過程中(alpha、Beta、RC)，也一直在科普并發(fā)特性，所以正式版發(fā)布時，已經(jīng)沒有什么新鮮特性。

本文主要講解v18發(fā)布日志中透露的一些未來發(fā)展趨勢。

開發(fā)者可能并不會接觸到并發(fā)特性

React對增加API是很慎重的。從13年誕生至今，觸發(fā)更新的方式都是this.setState。

而引入并發(fā)概念后，光是與并發(fā)相關(guān)的API就有好幾個，比如：

• useTransition。
• useDeferredValue。

甚至出現(xiàn)了為并發(fā)兜底的API(即并發(fā)情況下，不使用這些API可能會出bug)，比如：

• useSyncExternalStore。
• useInsertionEffect。

一下多出這么多API，還不是像useState這種不使用不行的API，況且，并發(fā)這一特性對于多數(shù)前端開發(fā)者都有些陌生。

你可以代入自己的業(yè)務(wù)想想，讓開發(fā)者上手使用并發(fā)特性有多難。

所以，在未來用v18開發(fā)的應(yīng)用，「開發(fā)者可能并不會接觸到并發(fā)特性」。這些特性更可能是由各種庫封裝好的。

比如：startTransition可以讓用戶在不同視圖間切換的同時，不阻塞用戶輸入。

這一API很可能會由各種Router實現(xiàn)，再作為一個配置項開放給開發(fā)者。

萬物皆可Suspense

對于React來說，有兩類瓶頸需要解決：

• CPU的瓶頸，如大計算量的操作導(dǎo)致頁面卡頓。
• IO的瓶頸，如請求服務(wù)端數(shù)據(jù)時的等待時間。

其中CPU的瓶頸通過并發(fā)特性的優(yōu)先級中斷機(jī)制解決。

IO的瓶頸則交給Suspense解決。

所以，未來一切與IO相關(guān)的操作，都會收斂到Suspense這一解決方案內(nèi)。

從最初的React.lazy到如今仍在開發(fā)中的Server Components，最終萬物皆可Suspense。

這其中有些邏輯是很復(fù)雜的，比如：

• Server Components。
• 新的服務(wù)端渲染方案。

所以，這些操作不大可能是直接面向開發(fā)者的。

這又回到了上一條，這些操作會交由各種庫實現(xiàn)。如果復(fù)雜度更高，則會交由基于React封裝的框架實現(xiàn)，比如Next.js、Remix。

這也是為什么React團(tuán)隊核心人物Sebastian會加入Next.js。

可以說，React未來的定位是：一個前端底層操作系統(tǒng)，足夠復(fù)雜，一般開發(fā)者慎用。

而開發(fā)者使用的是「基于該操作系統(tǒng)實現(xiàn)的各種上層應(yīng)用」。

總結(jié)

如果說v16之前各種React Like庫還能靠體積、性能優(yōu)勢分走React部分蛋糕，那未來兩者走的完全是兩條賽道，因為兩者的生態(tài)不再兼容。

未來不再會有React全家桶的概念，桶里的各個部件最終會淪為更大的框架中的一個小模塊。

當(dāng)前你們業(yè)務(wù)里是直接使用React呢，還是使用各種框架(比如Next.js)?