非 React 使用者估計(jì)看了都要搖頭啊。一個(gè)破回調(diào)函數(shù)的運(yùn)用，居然能折騰出來這么多事。一大堆文章都在探討如何使用它更合理。事實(shí)上確實(shí)如此，在 React 獨(dú)特的單向數(shù)據(jù)流刷新機(jī)制下，對(duì)于 useCallback 認(rèn)知的逐漸深入實(shí)際上也代表著對(duì) React 本身這個(gè)機(jī)制的理解更進(jìn)一步，因此在你徹底消化 React 刷新機(jī)制之前，這個(gè)過程中的每一個(gè)知識(shí)點(diǎn)可能都有巨大的探討空間

前幾天我的一位學(xué)生跟我探討了一種 useCallback 的用法，他的想法是：當(dāng)我們?cè)诜庋b開源工具庫時(shí)，對(duì)自定義 hook 中暴露出來的鉤子函數(shù)使用 useCallback 緩存。因?yàn)槲覀儾⒉淮_定使用者是否需要一個(gè)引用穩(wěn)定的鉤子函數(shù)，他們有可能是需要的，因此用 useCallback 來包一層是有意義的。但是他并不確定這樣的做法是否合適，是否具備較大的正向收益。

那么我就借著這個(gè)案例，來跟大家探討一下，我們?cè)?React 進(jìn)階的過程中，使用 useCallback 的四個(gè)階段。

階段一：敬畏

這個(gè)時(shí)候你還是一個(gè)初學(xué)者，對(duì) React 的理解還不夠深刻不夠全面，但是常?？吹轿恼?，或者聽別人說 useCallback 跟性能優(yōu)化有關(guān)，可對(duì)于你而言，你并不是非常清楚它跟性能優(yōu)化的具體關(guān)系在哪里，想知道，但不知道或者不夠確定，因此對(duì)這個(gè) hook api 有一種敬畏之心，各個(gè)論壇里對(duì)于 useCallback 的介紹很多很嘲雜，但你不敢隨便用。

因此你很想去看看別人的代碼里，useCallback 是怎么用的，是在什么場(chǎng)景下使用的，但是想要看到別人的代碼也并不容易，因此你可能會(huì)在這個(gè)階段徘徊。

階段二：懂了

隨著學(xué)習(xí)的深入，你逐漸開始深入理解了 React 的單向數(shù)據(jù)流機(jī)制，也對(duì) React 的使用更加熟練，知道 React 經(jīng)常會(huì)存在許多 re-render，你終于搞懂了 useCallback 的使用場(chǎng)景，它結(jié)合 React.memo 能夠緩存組件，避免組件的冗余 re-render。

于是你在項(xiàng)目中大量的使用了他們，就像當(dāng)初 PureComponent 一樣，你恨不得每個(gè)函數(shù)都用 useCallback 套一層，以確保自己的項(xiàng)目能最大限度減少 re-render，從而達(dá)到一個(gè)極致的性能體驗(yàn)。

function App() {
  ...

  const clickHankler = useCallback(() => {
    ...
  }, [count])

  const onOpen = useCallback(() => {
    ...
  }, [])
  
  ...
}

但是不管你用還不用，是大量使用還是大量不使用，從頁面的運(yùn)行結(jié)果中，都看不出來你這樣寫帶來了什么實(shí)質(zhì)的提升，甚至你有可能在依賴項(xiàng)的使用上感到難受，因?yàn)殚]包的影響導(dǎo)致實(shí)際運(yùn)行結(jié)果跟你預(yù)想的有出入。但是你能明確感受到 re-render 次數(shù)減少了。因此這個(gè)階段你非常堅(jiān)信自己達(dá)到了性能優(yōu)化的目的。

直到一次偶然的面試中，你被面試官一個(gè)問題問得啞口無言：只用 useCallback 能達(dá)到減少 re-render 的次數(shù)嗎？為什么？

階段三：精通

聽了我的直播分享，徹底搞懂了 React 的底層 DIFF 機(jī)制，你發(fā)現(xiàn)原來在 React 底層機(jī)制的邏輯下，我們大量的緩存工作其實(shí)是沒有必要的。React.memo 也有不小的使用成本，有的時(shí)候他的損耗不一定比 re-render 更低，于是你懂得了如何在項(xiàng)目中合理的使用 useCallback + React.memo，一通優(yōu)化下來，項(xiàng)目里的 useCallback 都被刪得差不多了，只在關(guān)鍵位置剩下幾個(gè)。

優(yōu)化的結(jié)果很理想，re-render 的情況不僅沒有變多，項(xiàng)目還減負(fù)了，性能又得到了提升，你很開心很有成就感。心想我終于又有了成長(zhǎng)，再次遇到上次那個(gè)面試官，我必定能吊打他。

階段四：貫通

你終于明白了 useCallback 只是一個(gè)非常普通的記憶函數(shù)。在 React hooks 特定的機(jī)制下記憶函數(shù)本身就被大量運(yùn)用。React 的許多 hook 都有類似的記憶能力，useCallback 只是最普通的那一個(gè)，另外的 hook 都在記憶能力的基礎(chǔ)之上又添加了一些別的語義。

useState
useEffect
useLayoutEffect
useCallback
useMemo
useRef
useReducer
useSyncExternalStore
...

這個(gè)階段你不再特殊看待他，在你的知識(shí)結(jié)構(gòu)里面你也不再特意的把他跟性能優(yōu)化掛上勾，而是把他標(biāo)記為一個(gè)記憶函數(shù)，他能夠保持一個(gè)函數(shù)的引用，當(dāng)你在 React 這個(gè)不穩(wěn)定的上下文環(huán)境中過，需要一個(gè)穩(wěn)定的引用時(shí)，你才會(huì)使用 useCallback。

因此，當(dāng)你在封裝一個(gè)開源工具庫時(shí)，你想到了你會(huì)對(duì)外拋出一個(gè)鉤子函數(shù)，但是你并不確定使用者會(huì)如何使用這個(gè)鉤子函數(shù)，使用者有可能會(huì)把他傳遞給子組件，此時(shí)如果鉤子函數(shù)引用不穩(wěn)，那么就有可能導(dǎo)致子組件 re-render。

例如在我們前面學(xué)習(xí)自定義 hook 的文章中，我們封裝了一個(gè) hook useFetch，代碼如下：

import { useState, useRef, useLayoutEffect } from 'react'

type API<T, P> = (param?: P) => Promise<T>

export default function useFetch<T, P>(api: API<T, P>) {
  const param = useRef<P>()
  const [list, setList] = useState<T>()
  const [error, setError] = useState('')
  const [loading, setLoading] = useState(true)

  function getList() {
    api(param.current).then(res => {
      setList(res)
      setLoading(false)
      setError('')
    }).catch(err => {
      setLoading(false)
      setError(err)
    })
  }

  useLayoutEffect(() => {
    loading && getList()
  }, [loading])

  return { 
    param, 
    setParam: (p: P) => param.current = p,
    list, 
    error, 
    loading, 
    setLoading 
  }
}

我們可以看到代碼里，在這個(gè)自定義 hook 中，返回了兩個(gè)鉤子函數(shù) setLoading setParam。

為了驗(yàn)證他們的引用是否穩(wěn)定，我們?cè)谑褂?useFectch 的組件中使用如下代碼來驗(yàn)證函數(shù)的引用是否發(fā)生了變化。

useEffect(() => {
  console.log('setLoading')
}, [setLoading])

驗(yàn)證結(jié)果非常神奇，setLoading 的引用居然非常的穩(wěn)定。但對(duì)于此時(shí)的你來說，這并沒有什么值得奇怪的地方。因?yàn)樗侵苯訌?useState 中獲取出來的。useState 本身就具備記憶能力，因此對(duì)于 setLoading 來說，我們不再需要想任何辦法來讓他的引用來保持穩(wěn)定。

setParam 跟預(yù)期一樣，一點(diǎn)也不穩(wěn)定，每次狀態(tài)變化，他的引用都會(huì)發(fā)生變化。因?yàn)樵诙x它的時(shí)候，每次都是新生成的函數(shù)給他賦值。

return { 
    param, 
+    setParam: (p: P) => param.current = p,
    list, 
    error, 
    loading, 
    setLoading 
  }

此時(shí)到了 useCallback 大展身手的時(shí)候了，我們使用 useCallback 包一層。

return { 
    param, 
-    setParam: (p: P) => param.current = p,
+    setParam: useCallback((p: P) => param.current = p, []),
    list, 
    error, 
    loading, 
    setLoading 
  }

再次驗(yàn)證，發(fā)現(xiàn)引用果然變穩(wěn)定了。nice。

但是你害怕這樣做有什么你沒想到的點(diǎn)，因?yàn)?useCallback 太善變了，所以你就跑來跟我溝通，想確定一下這樣子做到底能不能帶來很大的正向收益。

萬萬沒想到，我一開口就說：沒必要。

我引導(dǎo)你去看一下引用穩(wěn)定的 setLoading 是如何使用的，你就去翻了一下代碼，結(jié)果一看，壞事了，setLoading 因?yàn)閭髁艘粋€(gè)參數(shù)，導(dǎo)致在使用的時(shí)候又套了一層函數(shù)。

代碼如下。此時(shí) onClick 接收到的還是一個(gè)引用不穩(wěn)定的匿名函數(shù)... setLoading 的引用白考慮了。

<Button
  className={s.button}
  onClick={() => setLoading(true)}
>

然后你又看了一眼 setParam 的使用，還是這么個(gè)情況。

<input
  className={s.input}
  placeholder="請(qǐng)輸入您要搜索的內(nèi)容"
  onChange={(e) => setParam(e.target.value)}
/>

最后一想，發(fā)現(xiàn)好像 useCallback 又做了無用功。

至此，你徹底悟了。

就說總有一種不確定感，原來少考慮了一步。當(dāng)自定義 hook 傳出來的 函數(shù)在執(zhí)行時(shí)需要傳入?yún)?shù)時(shí)，就不得不在這個(gè)函數(shù)外面包一層匿名函數(shù)，再傳遞給子組件使用，如果它不需要參數(shù)，useCallback 才會(huì)發(fā)揮它的效果。

function useRouter() {
  const { dispatch } = useContext(RouterStateContext);

  const navigate = useCallback((url) => {
    dispatch({ type: 'navigate', url });
  }, [dispatch]);

  const goBack = useCallback(() => {
    dispatch({ type: 'back' });
  }, [dispatch]);

  return {
    navigate,
    goBack,
  };
}

const {goBack} = useRouter()

... 

<Child onBack={goBack}  />

當(dāng)真是真是步步驚心啊。

你終于悟到了要結(jié)合實(shí)際使用的場(chǎng)景去考慮使用 useCallback 的準(zhǔn)確時(shí)機(jī)，自此，融匯貫通成就達(dá)成。