陷進到處都是啊!本篇文章就說說Hooks使用時存在所謂的閉包陷阱,看看下面代碼:
function Chat() { const [text, setText] = useState(''); const onClick = useCallback(() => { sendMessage(text); }, []); return <SendButton onClick={onClick} />; }
想要實現(xiàn)的是點擊后sendMessage能傳遞text的最新值。
可卻無法實現(xiàn),就是由于回調(diào)函數(shù)被useCallback緩存,形成閉包,所以點擊的效果始終是sendMessage('')。
這就是閉包陷阱。
以上代碼的一種解決方式是為useCallback增加依賴項:
const onClick = useCallback(() => { sendMessage(text); }, [
text]);
上面操作之后,每當依賴項(text)變化,useCallback會返回一個全新的onClick引用,這就失去了useCallback緩存函數(shù)引用的作用。
閉包陷阱的出現(xiàn),加大了Hooks的上手門檻,這樣的bug在代碼中很容易發(fā)現(xiàn)。
看看React官方團隊解決這個問題。
useEvent
解決方式是引入一個新的原生Hook——useEvent。
他用于定義一個函數(shù),這個函數(shù)有2個特性:
在組件多次render時保持引用一致
函數(shù)內(nèi)始終能獲取到最新的props與state
上面的例子使用useEvent改造后:
function Chat() { const [text, setText] = useState(''); const onClick = useEvent(() => { sendMessage(text); }); return <SendButton onClick={onClick} />; }
在Chat組件多次render時,onClick始終指向同一個引用。
并且onClick觸發(fā)時始終能獲取到text的最新值。
之所以叫useEvent,是因為React團隊認為這個Hook的主要應(yīng)用場景是:封裝事件處理函數(shù)。
useEvent的實現(xiàn)
useEvent的實現(xiàn)并不困難,代碼類似如下:
function useEvent(handler) { const handlerRef = useRef(null); // 視圖渲染完成后更新`handlerRef.current`指向 useLayoutEffect(() => { handlerRef.current = handler; }); // 用useCallback包裹,使得render時返回的函數(shù)引用一致 return useCallback((...args) => { const fn = handlerRef.current; return fn(...args); }, []); }
整體包括兩部分:
返回一個沒有依賴項的useCallback,使得每次render時函數(shù)的引用一致
useCallback((...args) => { const fn = handlerRef.current; return fn(...args); }, []);
在合適的時機更新handlerRef.current,使得實際執(zhí)行的函數(shù)始終是最新的引用
與開源Hooks的差異
要知道現(xiàn)在很多開源Hooks庫已經(jīng)實現(xiàn)類似功能(比如ahooks中的useMemoizedFn)
useEvent與這些開源實現(xiàn)的差異主要體現(xiàn)在:
useEvent定位于處理事件回調(diào)函數(shù)這一單一場景,而useMemoizedFn定位于緩存各種函數(shù)。
那么問題來了,既然功能類似,那useEvent為什么要限制自己的使用場景呢?
答案是:為了更穩(wěn)定。
useEvent能否獲取到最新的state與props取決于handlerRef.current更新的時機。
在上面模擬實現(xiàn)中,useEvent更新handlerRef.current的邏輯放在useLayoutEffect回調(diào)中進行。
這就保證了handlerRef.current始終在視圖完成渲染后再更新:
useLayoutEffect(() => { handlerRef.current = handler; });
而事件回調(diào)觸發(fā)的時機顯然在視圖完成渲染之后,所以能夠穩(wěn)定獲取到最新的state與props。
注:源碼內(nèi)的實際更新時機會更早些,但不影響這里的結(jié)論
再來看看ahooks中的useMemoizedFn,fnRef.current的更新時機是useMemoizedFn執(zhí)行時(即組件render時):
function useMemoizedFn<T extends noop>(fn: T) { const fnRef = useRef<T>(fn); // 更新fnRef.current fnRef.current = useMemo(() => fn, [fn]); // ...省略代碼 }
當React18啟用并發(fā)更新后,組件render的次數(shù)、時機并不確定。
所以useMemoizedFn中fnRef.current的更新時機也是不確定的。
這就增加了在并發(fā)更新下使用時潛在的風險。
可以說,useEvent通過限制handlerRef.current更新時機,進而限制應(yīng)用場景,最終達到穩(wěn)定的目的。
總結(jié)
useEvent當前還處于RFC(Request For Comments)階段。
很多熱心的開發(fā)者對這個Hook的命名提出了建議,比如:useStableCallback:
又比如:useLatestClosure:
上面其實就是要擴大了useEvent的應(yīng)用場景。
但擴大后應(yīng)用場景意味著增加開發(fā)者使用時出錯的風險,這是不可行的。希望大家多多學習。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://www.ezyhdfw.cn/yun/128258.html
本文不會過多講解基礎(chǔ)知識,更多說的是在使用useRef如何能擺脫 這個 閉包陷阱 ? react hooks 的閉包陷阱 基本每個開發(fā)員都有遇見,這是很令人抓狂的?! ?以下react示范demo,均為react 16.8.3 版本) 列一個具體的場景: functionApp(){ const[count,setCount]=useState(1); useEffect(()=...
想必大家都能看得懂的源碼 ahooks 整體架構(gòu)篇,且可以使用插件化機制優(yōu)雅的封裝你的請求hook,現(xiàn)在我們就探討下ahooks 是怎么解決 React 的閉包問題的?。 React 的閉包問題 先來看一個例子: importReact,{useState,useEffect}from"react"; exportdefault()=>{ const[c...
摘要:比如就是一種,它可以用來管理狀態(tài)返回的結(jié)果是數(shù)組,數(shù)組的第一項是值,第二項是賦值函數(shù),函數(shù)的第一個參數(shù)就是默認值,也支持回調(diào)函數(shù)。而之所以輸出還是正確的,原因是的回調(diào)函數(shù)中,值永遠指向最新的值,因此沒有邏輯漏洞。 1. 引言 如果你在使用 React 16,可以嘗試 Function Component 風格,享受更大的靈活性。但在嘗試之前,最好先閱讀本文,對 Function Com...
摘要:當組件安裝和更新時,回調(diào)函數(shù)都會被調(diào)用。好在為我們提供了第二個參數(shù),如果第二個參數(shù)傳入一個數(shù)組,僅當重新渲染時數(shù)組中的值發(fā)生改變時,中的回調(diào)函數(shù)才會執(zhí)行。 前言 首先歡迎大家關(guān)注我的Github博客,也算是對我的一點鼓勵,畢竟寫東西沒法獲得變現(xiàn),能堅持下去也是靠的是自己的熱情和大家的鼓勵,希望大家多多關(guān)注呀!React 16.8中新增了Hooks特性,并且在React官方文檔中新增...
摘要:對于所訪問的每個元素,函數(shù)應(yīng)該將該元素傳遞給所提供的回調(diào)函數(shù)。 HTML 在線閱讀Github地址 題目列表 HTML HTML和XHTML的區(qū)別 Html的語義化 Doctype的文檔類型 cookie、sessionSttorage、localStory區(qū)別 HTML全局屬性(global attribute)有哪些? 常見的瀏覽器內(nèi)核有哪些? 介紹一下你對瀏覽器內(nèi)核的理解?...
閱讀 686·2023-03-27 18:33
閱讀 888·2023-03-26 17:27
閱讀 752·2023-03-26 17:14
閱讀 736·2023-03-17 21:13
閱讀 665·2023-03-17 08:28
閱讀 2084·2023-02-27 22:32
閱讀 1518·2023-02-27 22:27
閱讀 2431·2023-01-20 08:28