大家好，我卡頌。

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

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

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

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

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

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

• useTransition。
• useDeferredValue。

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

• useSyncExternalStore。
• useInsertionEffect。

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

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

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

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

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

萬物皆可Suspense

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

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

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

IO的瓶頸則交給Suspense解決。

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

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

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

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

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

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

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

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

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

總結(jié)

如果說v16之前各種React Like庫(kù)還能靠體積、性能優(yōu)勢(shì)分走React部分蛋糕，那未來兩者走的完全是兩條賽道，因?yàn)閮烧叩纳鷳B(tài)不再兼容。

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

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