自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

React官方團隊出手,補齊原生Hook短板

開發(fā) 前端
useEvent定位于「處理事件回調(diào)函數(shù)」這一單一場景,而useMemoizedFn定位于「緩存各種函數(shù)」。

大家好,我卡頌。

我們知道,Hooks使用時存在所謂的「閉包陷阱」,考慮如下代碼:

function Chat() {
const [text, setText] = useState('');

const onClick = useCallback(() => {
sendMessage(text);
}, []);

return <SendButton onClick={onClick} />;
}

我們期望點擊后sendMessage能傳遞text的最新值。

然而實際上,由于回調(diào)函數(shù)被useCallback緩存,形成閉包,所以點擊的效果始終是sendMessage('')。

這就是「閉包陷阱」。

以上代碼的一種解決方式是「為useCallback增加依賴項」:

const onClick = useCallback(() => {
sendMessage(text);
}, [text]);

但是這么做了后,每當(dāng)依賴項(text)變化,useCallback會返回一個全新的onClick引用,這就失去了useCallback「緩存函數(shù)引用」的作用。

「閉包陷阱」的出現(xiàn),加大了Hooks的上手門檻,也讓開發(fā)者更容易寫出有bug的代碼。

現(xiàn)在,React官方團隊要出手解決這個問題。

useEvent

解決方式是引入一個新的原生Hook —— useEvent。

他用于定義一個函數(shù),這個函數(shù)有2個特性:

  1. 在組件多次render時保持引用一致。
  2. 函數(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團隊認(rèn)為這個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的差異

很多開源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]);
// ...省略代碼
}

當(dāng)React18啟用「并發(fā)更新」后,組件render的次數(shù)、時機并不確定。

所以useMemoizedFn中fnRef.current的更新時機也是不確定的。

這就增加了在「并發(fā)更新」下使用時潛在的風(fēng)險。

可以說,useEvent通過限制handlerRef.current更新時機,進而限制應(yīng)用場景,最終達(dá)到穩(wěn)定的目的。

總結(jié)

useEvent當(dāng)前還處于RFC(Request For Comments)[1]階段。

很多熱心的開發(fā)者對這個Hook的命名提出了建議,比如:useStableCallback:

又比如:useLatestClosure:

從這些命名看,他們顯然擴大了useEvent的應(yīng)用場景。

經(jīng)過本文的分析我們知道,「擴大應(yīng)用場景」意味著「增加開發(fā)者使用時出錯的風(fēng)險」。

參考資料

[1]RFC(Request For Comments):

https://github.com/reactjs/rfcs/blob/useevent/text/0000-useevent.md。

責(zé)任編輯:姜華 來源: 魔術(shù)師卡頌
相關(guān)推薦

2024-02-26 00:20:00

AI模型

2012-11-30 10:52:57

低功耗ARM軟件

2020-04-28 18:47:06

微信微信群移動應(yīng)用

2022-08-23 11:40:34

數(shù)據(jù)云計算安全

2021-10-19 06:04:23

智能家居智能化物聯(lián)網(wǎng)

2024-07-16 09:51:39

HTMLHookReact

2022-04-14 11:50:39

函數(shù)組件hook

2020-07-29 08:28:47

5G醫(yī)療技術(shù)

2018-09-13 10:42:00

工具代碼機器學(xué)習(xí)

2021-05-17 15:07:02

5G電力技術(shù)

2023-08-01 08:26:32

2024-11-06 10:22:23

數(shù)據(jù)安全Akamai

2019-04-25 10:20:24

Transformer神經(jīng)網(wǎng)絡(luò)模型

2022-08-01 07:56:23

React Hook開發(fā)組件

2020-10-21 11:34:49

React Hook庫

2020-09-20 17:50:24

大數(shù)據(jù)IT互聯(lián)網(wǎng)

2024-10-16 13:50:00

模型AI

2020-01-07 15:40:43

React前端技術(shù)準(zhǔn)則

2020-11-02 11:44:41

辦公

2020-09-08 15:24:11

iOS 14提醒事項功能
點贊
收藏

51CTO技術(shù)棧公眾號