?不數(shù)不知道，React已經(jīng)有22個(gè)Hook了

作者：卡頌 2023-06-06 07:41:00

如果說(shuō)CSR時(shí)期的hook都是面向開(kāi)發(fā)者直接使用的。那么并發(fā)時(shí)期最初的2個(gè)Hook（useTransition、useDeferredValue）已經(jīng)鮮有開(kāi)發(fā)者使用了，而后期類(lèi)似useMutableSource這樣的Hook，普通開(kāi)發(fā)者則根本用不到。

大家好，我卡頌。

5月30日剛好是React10周年紀(jì)念日。

我順手拉了下React最新代碼，這一看不要緊，居然已經(jīng)有22個(gè)hook了。

其中：

react包導(dǎo)出了21個(gè)。
react-dom包導(dǎo)出了1個(gè)（useFormStatus）。

本文會(huì)從React這些年發(fā)展脈絡(luò)的角度，聊聊這些hook的作用。

時(shí)代的更迭

截止當(dāng)前，React的發(fā)展主要經(jīng)歷了3個(gè)時(shí)期：

CSR時(shí)期（客戶(hù)端渲染時(shí)期）
并發(fā)時(shí)期
RSC時(shí)期（服務(wù)端組件時(shí)期）

當(dāng)前的22個(gè)hook也都是這3個(gè)時(shí)期的產(chǎn)物。

CSR時(shí)期

時(shí)間回到2013年，為了解決facebook日益復(fù)雜的交互，「jordwalke」開(kāi)發(fā)了React。經(jīng)過(guò)一段時(shí)間摸索，React逐漸形成一套滿(mǎn)足CSR的開(kāi)發(fā)模式。

這套開(kāi)發(fā)模式從ClassComponent遷移到FunctionComponent后，便形成了最初的一批hook。這些hook都與CSR的開(kāi)發(fā)模式相關(guān)。比如：

與狀態(tài)的流轉(zhuǎn)相關(guān)的：

useState
useReducer
useContext

與處理副作用相關(guān)的：

useEffect
useLayoutEffect

與提高操作自由度相關(guān)的：

useRef

與性能優(yōu)化相關(guān)的：

useMemo
useCallback

與調(diào)試相關(guān)：

useDebugValue

隨著React持續(xù)迭代，又引入了幾個(gè)hook，本質(zhì)來(lái)說(shuō)他們都是為了完善CSR的開(kāi)發(fā)模式，對(duì)現(xiàn)有hook能力進(jìn)行補(bǔ)充或約束：

useImperativeHandle（控制useRef防止其失控）
useEffectEvent（對(duì)useEffect能力的補(bǔ)充）
useInsertionEffect（對(duì)useEffect場(chǎng)景的補(bǔ)充）
useMemoCache[1]（減少性能優(yōu)化心智負(fù)擔(dān)）

這里簡(jiǎn)單聊聊useMemoCache。長(zhǎng)久以來(lái)，不管是ClassComponent的shouldComponentUpdate，還是FC中2個(gè)性能優(yōu)化相關(guān)hook，都存在比較重的心智負(fù)擔(dān)，比如：

開(kāi)發(fā)者需要考慮是否需要性能優(yōu)化
開(kāi)發(fā)者需要考慮何時(shí)使用useMemo、useCallback

為了解決這個(gè)問(wèn)題，在2021年的React Conf，黃玄帶來(lái)了「能夠通過(guò)編譯器生成等效于useMemo、useCallback代碼」的方案 —— React Forget。

useMemoCache就是React內(nèi)部為React Forget提供緩存支持的hook。

所以這個(gè)hook是給編譯器用的，而不是我們普通開(kāi)發(fā)者。

并發(fā)時(shí)期

在13年誕生之初，React的作者「jordwalke」就指出 —— React未來(lái)會(huì)發(fā)展「并發(fā)特性」。

這并不是什么高瞻遠(yuǎn)矚的預(yù)言，React本身是個(gè)重運(yùn)行時(shí)的框架，這意味著他的迭代方向需要圍繞「運(yùn)行時(shí)」展開(kāi)。而「并發(fā)特性」是一種優(yōu)秀的運(yùn)行時(shí)性能優(yōu)化策略。

隨著并發(fā)特性落地，首先推出的是2個(gè)并發(fā)相關(guān)hook：

useTransition
useDeferredValue

這2個(gè)hook的本質(zhì)都是降低更新的優(yōu)先級(jí)，「更新」意味著「視圖渲染」，所以當(dāng)更新?lián)碛胁煌瑑?yōu)先級(jí)后，這意味著「視圖渲染」擁有不同優(yōu)先級(jí)。

這就是并發(fā)更新的理論基礎(chǔ)。

但是，并發(fā)更新的出現(xiàn)，打破了React沿襲多年的「一次更新對(duì)應(yīng)一次渲染」的模式。

為了讓現(xiàn)有的庫(kù)兼容并發(fā)模式，推出了如下hook：

useMutableSource
useSyncExternalStore

所以，上述2個(gè)hook主要是面向開(kāi)源庫(kù)作者。

RSC時(shí)期

RSC（服務(wù)端組件）是一個(gè)浩大的工程，他的實(shí)現(xiàn)不是一蹴而就的，這一點(diǎn)從新出的hook就能看出。

既然是服務(wù)端組件，那就涉及到組件在服務(wù)端渲染。那么，對(duì)于存在唯一標(biāo)識(shí)（比如下面的id props）的組件，如何保證這個(gè)唯一標(biāo)識(shí)在服務(wù)端與客戶(hù)端一致呢？

<SomeCpn id={id}/>

如果組件僅在一端渲染，簡(jiǎn)單使用Math.random()就能獲得唯一標(biāo)識(shí)：

const id = Math.random();

<SomeCpn id={id}/>

但如果這段邏輯在服務(wù)端/客戶(hù)端都運(yùn)行一次，顯然id就不唯一了。

為了生成在服務(wù)端/客戶(hù)端唯一的id，有了：

useId

在并發(fā)時(shí)期，由于引入了「渲染優(yōu)先級(jí)」的概念，那勢(shì)必存在一些由于優(yōu)先級(jí)不足，而處于pending中的渲染。

如何展示「渲染的pending狀態(tài)」呢？React引入了<Suspense>組件。

到了RSC時(shí)期，React團(tuán)隊(duì)發(fā)現(xiàn)，「渲染的pending狀態(tài)」是pending，「數(shù)據(jù)請(qǐng)求的pending狀態(tài)」不也是pending嗎？

換言之，任何需要中間pending狀態(tài)的流程，不都可以納入<Suspense>的管理范圍？

那該怎么標(biāo)記一個(gè)流程可以被納入<Suspense>的管理呢？于是有了：

通過(guò)這個(gè)hook聲明的流程中的pending狀態(tài)都會(huì)被納入<Suspense>的管理。

既然<Suspense>越來(lái)越重要，那我們是不是要針對(duì)他做些優(yōu)化？既然<Suspense>可以在不同視圖之間切換，那為他增加緩存顯然是種不錯(cuò)的優(yōu)化方式，于是有了：

useCacheRefresh[2]（用于建立<Suspense>緩存）

到這一步，RSC的基礎(chǔ)設(shè)施算是搭好了，下一步該構(gòu)建上層應(yīng)用了。

在瀏覽器端，與RSC理念最契合的便是form標(biāo)簽，圍繞form標(biāo)簽的action屬性，React推出了如下hook：

useOptimistic
useFormStatus

這2個(gè)hook都是為了優(yōu)化「表單提交」這一場(chǎng)景（也可以說(shuō)是RSC與客戶(hù)端的交互場(chǎng)景）。

關(guān)于這2個(gè)hook，更詳細(xì)的解釋可以參考form 元素是 React 的未來(lái)一文。

總結(jié)

如果說(shuō)CSR時(shí)期的hook都是面向開(kāi)發(fā)者直接使用的。那么并發(fā)時(shí)期最初的2個(gè)hook（useTransition、useDeferredValue）已經(jīng)鮮有開(kāi)發(fā)者使用了，而后期類(lèi)似useMutableSource這樣的hook，普通開(kāi)發(fā)者則根本用不到。

同樣的，再往后的RSC時(shí)期的所有hook，普通開(kāi)發(fā)者都用不到。他們都是為其他庫(kù)、框架（比如Next.js）提供的。

這標(biāo)志著React發(fā)展方向的不斷變化：