前言

推薦閱讀：# useMemo..一把梭？達咩！?|一文告訴你為什么React不把他們設(shè)為默認方法 #useEvent 是一個剛剛提案的原生Hook，還處于RFC。討論地址在這里~下面有些代碼就是來自其中

RFC：Request for Comments 提案還在廣泛的討論階段

沒有 useEvent 的時候??

我們先看看不用 useEvent 的情況：

function Chat() {
  const [text, setText] = useState('');
  // ?? Always a different function
  const onClick = () => {
    sendMessage(text);
  };
  return <SendButton onClick={onClick} />;
}

其中點擊事件的回調(diào)函數(shù) onClick 中需要讀取當前鍵入的文本text，這里的onClick隨著組件重新渲染一次次地重新創(chuàng)建，每次都會是不一樣的引用，這顯然帶來了性能損耗，如果你想對其進行優(yōu)化，你可能會這樣做：

function Chat() {
  const [text, setText] = useState('');
  // ?? A different function whenever `text` changes
  const onClick = useCallback(() => {
    sendMessage(text);
  }, [text]);
  return <SendButton onClick={onClick} />;
}

通過 useCallback 返回一個 memoized 回調(diào)函數(shù)。

useCallback： 返回一個 memoized 回調(diào)函數(shù)。 把內(nèi)聯(lián)回調(diào)函數(shù)及依賴項數(shù)組作為參數(shù)傳入 useCallback，它將返回該回調(diào)函數(shù)的 memoized 版本，該回調(diào)函數(shù)僅在某個依賴項改變時才會更新。當你把回調(diào)函數(shù)傳遞給經(jīng)過優(yōu)化的并使用引用相等性去避免非必要渲染（例如 shouldComponentUpdate）的子組件時，它將非常有用。 useCallback(fn, deps) 相當于 useMemo(() => fn, deps)。

最終使得onClick的引用始終不變但是！

onClcik這個方法有需要保證每次都要拿到最新的、正確的text，所以他的deps中就自然是設(shè)置了text—— 壞了，“又回到最初的起點~”。隨著每一次keystroke，onClick又變成了上面的情況：

 Always a different function

但你又不能將其從deps中移除，移除了他就只能拿到text的初始值，失去了他本該有的功能...

小 useEvent 來給他整個活??

useEvent就是為了解決此類問題，所以他干脆不要deps了，他就是一直返回一個相同的函數(shù)引用，哪怕text發(fā)生變化。當然，保證它也能拿到最新的、正確的**text**。

function Chat() {
  const [text, setText] = useState('');
  // ? Always the same function (even if `text` changes)
  const onClick = useEvent(() => {
    sendMessage(text);
  });
  return <SendButton onClick={onClick} />;
}

現(xiàn)在好了：

• onClick 的引用始終是同一個
• 保證每次都能拿到最新的、正確的 text

當然還有其他一些場景，但是大致需求原理相同，就是不想讓A因為b變化而總是重新加載，但是又因為要拿到b恰當?shù)闹担?code>deps中必須b，導(dǎo)致不得不重新加載，掉進了“圈圈圓圓圈圈~”的陷阱。更多場景這里就不再贅述。更多案例可查看文末的學習資源~

總而言之，用useEvent給他裹上就是香，就是可以同時達到上面兩個效果：

• 引用不變
• 拿到恰當?shù)闹?/li>

這是咋做到的??

說了這么多，我們來看看他這是咋做到的
他大概是這么個形狀：（不是源碼就長這樣的意思嗷）

// (!) Approximate behavior
function useEvent(handler) {
  const handlerRef = useRef(null);
  // In a real implementation, this would run before layout effects
  useLayoutEffect(() => {
    handlerRef.current = handler;
  });
  return useCallback((...args) => {
    // In a real implementation, this would throw if called during render
    const fn = handlerRef.current;
    return fn(...args);
  }, []);
}

先回顧幾個Hook相關(guān)知識點：

useRef

useRef:

useRef 返回一個可變的 ref 對象，其 .current 屬性被初始化為傳入的參數(shù)（initialValue）。返回的 ref 對象在組件的整個生命周期內(nèi)持續(xù)存在。

這里通過 useRef 保存回調(diào)函數(shù)handler到handlerRef.current，然后再在 useCallback 中從handlerRef.current來取函數(shù)再調(diào)用，這樣避免了直接調(diào)用，跳出了閉包陷阱。并且不出意外的話handler在整個生命周期內(nèi)持續(xù)存在，也就是只有一個引用。

useLayoutEffect

這個 useLayoutEffect 可能沒那么常用，我們來看看這是啥嘞

其函數(shù)簽名與 useEffect 相同，但它會在所有的 DOM 變更之后同步調(diào)用 effect?？梢允褂盟鼇碜x取 DOM 布局并同步觸發(fā)重渲染。在瀏覽器執(zhí)行繪制之前，useLayoutEffect 內(nèi)部的更新計劃將被同步刷新。

useEffect

回顧一下 useEffect

默認情況下，effect 將在每輪渲染結(jié)束后執(zhí)行

兩者的區(qū)別

好了，現(xiàn)在我給你用一個字總結(jié)一下兩者區(qū)別，useLayoutEffect 更“快”！這個“塊”不是速度更快，而是他“搶跑”了哩。useLayoutEffect 是在render之前同步執(zhí)行，useEffect在render之后異步執(zhí)行，這里就是保證useLayoutEffect 里的回調(diào)肯定比useEffect更早前被調(diào)用、被執(zhí)行。

useCallback執(zhí)行時機

前面說到

useCallback(fn, deps) 相當于 useMemo(() => fn, deps)。

文檔里是這樣說 useMemo 的：

記住，傳入 useMemo 的函數(shù)會在渲染期間執(zhí)行。請不要在這個函數(shù)內(nèi)部執(zhí)行與渲染無關(guān)的操作，諸如副作用這類的操作屬于 useEffect 的適用范疇，而不是 useMemo。

也就是他是在render時執(zhí)行的，也就是保證了賦值handler給handlerRef.current是在前面發(fā)生

這里的作用

這里返回的是一個useCallback包裹后 memoized函數(shù)，其中從handlerRef.current中獲取函數(shù)，并且deps為[]，也就是說他不會再次更新。

捋一捋??

回顧完知識點我們也就濾清了這個useEvent方法，一句話總結(jié)就是：它接收一個回調(diào)函數(shù)handler作為參數(shù)，提供給你一個穩(wěn)定的函數(shù)（始終只有一個引用）并且調(diào)用時都是用的你傳入的最新的參數(shù)...args——比如前面案例中的text，始終都是最新的、正確的、恰當?shù)摹?/strong>再結(jié)合一開始的案例，大概流程就是這樣：