文章轉(zhuǎn)載自公眾號:前端之露
最近團隊內(nèi)有同學(xué),由于寫 react hooks 引發(fā)了一些 bug,甚至有 1 例是線上問題。團隊內(nèi)也因此發(fā)起了一些爭執(zhí),到底要不要寫 hooks?到底要不要加 lint?到底要不要加 autofix?爭論下來結(jié)論如下:
- 寫還是要寫的;
- 寫 hooks 前一定要先學(xué)習(xí) hooks;
- 團隊再出一篇必讀文檔,必須要求每位同學(xué),先讀再寫。
因此便有了此文。
本文主要講兩大點:
- 寫 hooks 前的硬性要求;
- 寫 hooks 常見的幾個注意點。
硬性要求
1. 必須完整閱讀一次 React Hooks 官方文檔
英文文檔:https://reactjs.org/docs/hooks-intro.html
中文文檔:https://zh-hans.reactjs.org/docs/hooks-intro.html
其中重點必看 hooks: useState
、useReducer
、useEffect
、useCallback
、useMemo
另外推薦閱讀:
- Dan的《useEffect完全指南》
- 衍良同學(xué)的《React Hooks完全上手指南》
2. 工程必須引入 lint 插件,并開啟相應(yīng)規(guī)則
lint 插件:https://www.npmjs.com/package/eslint-plugin-react-hooks 必開規(guī)則:
{
"plugins": ["react-hooks"],
"rules": {
"react-hooks/rules-of-hooks": "error",
"react-hooks/exhaustive-deps": "warn"
}
}
其中, react-hooks/exhaustive-deps
至少 warn,也可以是 error。建議全新的工程直接配 "error",歷史工程配 "warn"。
切記,本條是硬性條件。
如果你的工程,當前沒開啟 hooks lint rule
,請不要編寫任何 hooks
代碼。如果你 CR 代碼時,發(fā)現(xiàn)對方前端工程,沒有開啟相應(yīng)規(guī)則,并且提交了 hooks
代碼,請不要合并。該要求適應(yīng)于任何一個 React
前端工程。
這兩條規(guī)則會避免我們踩坑。雖然對于 hooks
新手,這個過程可能會比較“痛苦”。不過,如果你覺得這兩個規(guī)則對你編寫代碼造成了困擾,那說明你還未完全掌握 hooks。
如果對于某些場景,確實不需要「exhaustive-deps」,可在代碼處加:
// eslint-disable-next-line react-hooks/exhaustive-deps
切記只能禁本處代碼,不能偷懶把整個文件都禁了。
3. 如若有發(fā)現(xiàn) hooks 相關(guān) lint 導(dǎo)致的 warning,不要全局 autofix
除了 hooks
外,正常的 lint
基本不會改變代碼邏輯,只是調(diào)整編寫規(guī)范。但是 hooks
的 lint
規(guī)則不同,exhaustive-deps
的變化會導(dǎo)致代碼邏輯發(fā)生變化,這極容易引發(fā)線上問題,所以對于 hooks
的 waning
,請不要做全局 autofix
操作。除非保證每處邏輯都做到了充分回歸。
另外公司內(nèi)部有個小姐姐補充道:eslint-plugin-react-hooks
從2.4.0版本開始,已經(jīng)取消了 exhaustive-deps
的autofix。所以,請盡量升級工程的lint插件至最新版,減少出錯風(fēng)險。
然后建議開啟 vscode
的「autofix on save」。未來無論是什么問題,能把 error 與 warning 盡量遏制在最開始的開發(fā)階段,保證自測跟測試時就是符合規(guī)則的代碼。
常見注意點
依賴問題
依賴與閉包問題是一定要開啟exhaustive-deps
的核心原因。最常見的錯誤即:mount 時綁定事件,后續(xù)狀態(tài)更新出錯。
錯誤代碼示例:(此處用 addEventListener 做 onclick 綁定,只是為了方便說明情況)
function ErrorDemo() {
const [count, setCount] = useState(0);
const dom = useRef(null);
useEffect(() => {
dom.current.addEventListener('click', () => setCount(count + 1));
}, []);
return <div ref={dom}>{count}</div>;
}
這段代碼的初始想法是:每當用戶點擊 dom
,count
就加1。理想中的效果是一直點,一直加。但實際效果是 {count} 到「1」以后就加不上了。
我們來梳理一下, useEffect(fn, [])
代表只會在 mount 時觸發(fā)。也即是首次 render 時,fn 執(zhí)行一次,綁定了點擊事件,點擊觸發(fā) setCount(count + 1)
。乍一想,count 還是那個 count,肯定會一直加上去呀,當然現(xiàn)實在啪啪打臉。
狀態(tài)變更觸發(fā)頁面渲染的本質(zhì)是什么?本質(zhì)就是 ui = fn(props, state, context)
。props、內(nèi)部狀態(tài)、上下文的變更,都會導(dǎo)致渲染函數(shù)(此處就是ErrorDemo)的重新執(zhí)行,然后返回新的 view。
那現(xiàn)在問題來了, ErrorDemo
這個函數(shù)執(zhí)行了多次,第一次函數(shù)內(nèi)部的 count
跟后面幾次的 count
會有關(guān)系嗎?這么一想,感覺又應(yīng)該沒有關(guān)系了。那為什么第二次又知道 count 是1,而不是 0 了呢?第一次的setCount
跟后面的是同一個函數(shù)嗎?這背后涉及到 hooks 的一些底層原理,也關(guān)系到了為什么 hooks 的聲明需要聲明在函數(shù)頂部,不允許在條件語句中聲明。在這里就不多講了。
結(jié)論是:每次 count
都是重新聲明的變量,指向一個全新的數(shù)據(jù);每次的setCount
雖然是重新聲明的,但指向的是同一個引用。
回到正題,我們知道了每次 render,內(nèi)部的 count 其實都是全新的一個變量。那我們綁定的點擊事件方法,也即:setCount(count + 1)
,這里的 count,其實指的一直是首次 render 時的那個 count,所以一直是 0 ,因此 setCount,一直是設(shè)置 count 為1。
那這個問題怎么解?
首先,應(yīng)該遵守前面的硬性要求,必須要加 lint 規(guī)則,并開啟 autofix on save。然后就會發(fā)現(xiàn),其實這個 effect
是依賴 count
的。autofix 會幫你自動補上依賴,代碼變成這樣:
useEffect(() => {
dom.current.addEventListener('click', () => setCount(count + 1));
}, [count]);
那這樣肯定就不對了,相當于每次 count 變化,都會重新綁定一次事件。所以對于事件的綁定,或者類似的場景,有幾種思路,我按我的常規(guī)處理優(yōu)先級排列:
思路1:消除依賴
在這個場景里,很簡單,我們主要利用 setCount
的另一個用法 functional updates。這樣寫就好了:
() => setCount(prevCount => ++prevCount)
,不用關(guān)心什么新的舊的、什么閉包,省心省事。
思路2:重新綁定事件
那如果我們這個事件就是要消費這個 count 怎么辦?比如這樣:
dom.current.addEventListener('click', () => {
console.log(count);
setCount(prevCount => ++prevCount);
});
我們不必執(zhí)著于一定只在 mount 時執(zhí)行一次。也可以每次重新 render 前移除事件,render 后綁定事件即可。這里利用 useEffect 的特性,具體可以自己看文檔:
useEffect(() => {
const $dom = dom.current;
const event = () => {
console.log(count);
setCount(prev => ++prev);
};
$dom.addEventListener('click', event);
return () => $dom.removeEventListener('click', event);
}, [count]);
思路3:
如果嫌這樣開銷大,或者編寫麻煩,也可以用 useRef
其實用 useRef
也挺麻煩的,我個人不太喜歡這樣操作,但也能解決問題,代碼如下:
const [count, setCount] = useState(0);
const countRef = useRef(count);
useEffect(() => {
dom.current.addEventListener('click', () => {
console.log(countRef.current);
setCount(prevCount => {
const newCount = ++prevCount;
countRef.current = newCount;
return newCount;
});
});
}, []);
useCallback 與 useMemo
這兩個 api
,其實概念上還是很好理解的,一個是「緩存函數(shù)」, 一個是緩存「函數(shù)的返回值」。但我們經(jīng)常會懶得用,甚至有的時候會用錯。
從上面依賴問題我們其實可以知道,hooks
對「有沒有變化」這個點其實很敏感。如果一個 effect
內(nèi)部使用了某數(shù)據(jù)或者方法。若我們依賴項不加上它,那很容易由于閉包問題,導(dǎo)致數(shù)據(jù)或方法,都不是我們理想中的那個它。如果我們加上它,很可能又會由于他們的變動,導(dǎo)致 effect
瘋狂的執(zhí)行。真實開發(fā)的話,大家應(yīng)該會經(jīng)常遇到這種問題。
所以,在此建議:
- 在組件內(nèi)部,那些會成為其他 useEffect 依賴項的方法,建議用
useCallback
包裹,或者直接編寫在引用它的useEffect中。 - 己所不欲勿施于人,如果你的 function 會作為 props傳遞給子組件,請一定要使用
useCallback
包裹,對于子組件來說,如果每次render都會導(dǎo)致你傳遞的函數(shù)發(fā)生變化,可能會對它造成非常大的困擾。同時也不利于 react 做渲染優(yōu)化。
不過還有一種場景,大家很容易忽視,而且還很容易將 useCallback
與 useMemo
混淆,典型場景就是:節(jié)流防抖。
舉個例子:
function BadDemo() {
const [count, setCount] = useState(1);
const handleClick = debounce(() => {
setCount(c => ++c);
}, 1000);
return <div onClick={handleClick}>{count}</div>;
}
我們希望防止用戶連續(xù)點擊觸發(fā)多次變更,加了防抖,停止點擊1秒后才觸發(fā) count + 1
,這個組件在理想邏輯下是OK的。但現(xiàn)實是骨感的,我們的頁面組件非常多,這個 BadDemo
可能由于父級什么操作就重新 render 了?,F(xiàn)在假使我們頁面每500毫秒會重新 render 一次,那么就是這樣:
function BadDemo() {
const [count, setCount] = useState(1);
const [, setRerender] = useState(false);
const handleClick = debounce(() => {
setCount(c => ++c);
}, 1000);
useEffect(() => {
// 每500ms,組件重新render
window.setInterval(() => {
setRerender(r => !r);
}, 500);
}, []);
return <div onClick={handleClick}>{count}</div>;
}
每次 render 導(dǎo)致 handleClick
其實是不同的函數(shù),那么這個防抖自然而然就失效了。這樣的情況對于一些防重點要求特別高的場景,是有著較大的線上風(fēng)險的。
那怎么辦呢?自然是想加上 useCallback
:
const handleClick = useCallback(debounce(() => {
setCount(c => ++c);
}, 1000), []);
現(xiàn)在我們發(fā)現(xiàn)效果滿足我們期望了,但這背后還藏著一個驚天大坑。
假如說,這個防抖的函數(shù)有一些依賴呢?比如 setCount(c => ++c);
變成了 setCount(count + 1)
。那這個函數(shù)就依賴了 count
。代碼就變成了這樣:
const handleClick = useCallback(
debounce(() => {
setCount(count + 1);
}, 1000),
[]
);
大家會發(fā)現(xiàn),你的 lint 規(guī)則,竟然不會要求你把 count 作為依賴項,填充到 deps 數(shù)組中去。這進而導(dǎo)致了最初的那個問題,只有第一次點擊會 count++。這是為什么呢?
因為傳入 useCallback 的是一段執(zhí)行語句,而不是一個函數(shù)聲明。只是說它執(zhí)行以后返回的新函數(shù),我們將其作為了 useCallback
函數(shù)的入?yún)?,而這個新函數(shù)具體是個啥,其實 lint 規(guī)則也不知道。
更合理的姿勢應(yīng)該是使用 useMemo
:
const handleClick = useMemo(
() => debounce(() => {
setCount(count + 1);
}, 1000),
[count]
);
這樣保證每當 count
發(fā)生變化時,會返回一個新的加了防抖功能的新函數(shù)。
總而言之,對于使用高階函數(shù)的場景,建議一律使用 useMemo
有些網(wǎng)友提供了寶貴的反饋,我繼續(xù)補充:剛使用useMemo,依舊存在一些問題。
問題1:useMemo「將來」并不「穩(wěn)定」
react 的官方文檔中提到:你可以把 useMemo
作為性能優(yōu)化的手段,但不要把它當成語義上的保證。將來,React 可能會選擇“遺忘”以前的一些 memoized 值,并在下次渲染時重新計算它們,比如為離屏組件釋放內(nèi)存。先編寫在沒有 > useMemo
的情況下也可以執(zhí)行的代碼 —— 之后再在你的代碼中添加 > useMemo
,以達到優(yōu)化性能的目的。也就是說,在將來的某種特殊情況下,這個防抖函數(shù)依舊會失效。當然,這種情況是發(fā)生在「將來」,且相對比較極端,出現(xiàn)概率較小,即使出現(xiàn),也不會“短時間內(nèi)連續(xù)”出現(xiàn)。所以對于不是 「前端防不住抖就要完蛋」的場景,風(fēng)險相對較小。
問題2:useMemo 并不能一勞永逸解決所有高階函數(shù)場景
在示例的場景中,防抖的邏輯是:「連續(xù)點擊后1秒,真正執(zhí)行邏輯,在這過程中的重復(fù)點擊失效」。而如果業(yè)務(wù)邏輯改成了「點擊后立即發(fā)生狀態(tài)變更,再之后的1秒內(nèi)重復(fù)點擊無效」,那么我們的代碼可能就變成了。
const handleClick = useMemo(
() => throttle(() => { setCount(count + 1); }, 1000), [count] );
然后發(fā)現(xiàn)又失效了。原因是點擊以后,count 立即發(fā)生了變化,然后 handleClick 又重復(fù)生成了新函數(shù),這個節(jié)流就失效了。
所以這種場景,思路又變回了前面提到的,「消除依賴」 或 「使用ref」。
當然啦,也可以選擇自己手動實現(xiàn)一個 debounce
或 throttle
。我建議可以直接使用社區(qū)的庫,比如 react-use,或者參考他們的實現(xiàn)自己寫兩個實現(xiàn)。
以上就是W3Cschool編程獅
關(guān)于react hooks線上 bug后復(fù)盤的相關(guān)介紹了,希望對大家有所幫助。