建站
咨詢
售后
建站咨詢
新聞中心
非 React 使用者估計(jì)看了都要搖頭啊。一個(gè)破回調(diào)函數(shù)的運(yùn)用，居然能折騰出來這么多事。一大堆文章都在探討如何使用它更合理。事實(shí)上確實(shí)如此，在 React 獨(dú)特的單向數(shù)據(jù)流刷新機(jī)制下，對于 useCallback 認(rèn)知的逐漸深入實(shí)際上也代表著對 React 本身這個(gè)機(jī)制的理解更進(jìn)一步，因此在你徹底消化 React 刷新機(jī)制之前，這個(gè)過程中的每一個(gè)知識點(diǎn)可能都有巨大的探討空間
成都創(chuàng)新互聯(lián)公司專業(yè)提供四川雅安電信機(jī)房服務(wù)，為用戶提供五星數(shù)據(jù)中心、電信、雙線接入解決方案，用戶可自行在線購買四川雅安電信機(jī)房服務(wù)，并享受7*24小時(shí)金牌售后服務(wù)。
前幾天我的一位學(xué)生跟我探討了一種 useCallback 的用法，他的想法是：當(dāng)我們在封裝開源工具庫時(shí)，對自定義 hook 中暴露出來的鉤子函數(shù)使用 useCallback 緩存。因?yàn)槲覀儾⒉淮_定使用者是否需要一個(gè)引用穩(wěn)定的鉤子函數(shù)，他們有可能是需要的，因此用 useCallback 來包一層是有意義的。但是他并不確定這樣的做法是否合適，是否具備較大的正向收益。
那么我就借著這個(gè)案例，來跟大家探討一下，我們在 React 進(jìn)階的過程中，使用 useCallback 的四個(gè)階段。
階段一：敬畏
這個(gè)時(shí)候你還是一個(gè)初學(xué)者，對 React 的理解還不夠深刻不夠全面，但是常?？吹轿恼拢蛘呗爠e人說 useCallback 跟性能優(yōu)化有關(guān)，可對于你而言，你并不是非常清楚它跟性能優(yōu)化的具體關(guān)系在哪里，想知道，但不知道或者不夠確定，因此對這個(gè) hook api 有一種敬畏之心，各個(gè)論壇里對于 useCallback 的介紹很多很嘲雜，但你不敢隨便用。
因此你很想去看看別人的代碼里，useCallback 是怎么用的，是在什么場景下使用的，但是想要看到別人的代碼也并不容易，因此你可能會在這個(gè)階段徘徊。
階段二：懂了
隨著學(xué)習(xí)的深入，你逐漸開始深入理解了 React 的單向數(shù)據(jù)流機(jī)制，也對 React 的使用更加熟練，知道 React 經(jīng)常會存在許多 re-render，你終于搞懂了 useCallback 的使用場景，它結(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ù)了，性能又得到了提升，你很開心很有成就感。心想我終于又有了成長，再次遇到上次那個(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è)階段你不再特殊看待他，在你的知識結(jié)構(gòu)里面你也不再特意的把他跟性能優(yōu)化掛上勾，而是把他標(biāo)記為一個(gè)記憶函數(shù)，他能夠保持一個(gè)函數(shù)的引用，當(dāng)你在 React 這個(gè)不穩(wěn)定的上下文環(huán)境中過，需要一個(gè)穩(wěn)定的引用時(shí)，你才會使用 useCallback。
因此，當(dāng)你在封裝一個(gè)開源工具庫時(shí)，你想到了你會對外拋出一個(gè)鉤子函數(shù)，但是你并不確定使用者會如何使用這個(gè)鉤子函數(shù)，使用者有可能會把他傳遞給子組件，此時(shí)如果鉤子函數(shù)引用不穩(wěn)，那么就有可能導(dǎo)致子組件 re-render。
例如在我們前面學(xué)習(xí)自定義 hook 的文章中，我們封裝了一個(gè) hook useFetch，代碼如下：
import { useState, useRef, useLayoutEffect } from 'react'
type API = (param?: P) => Promise
export default function useFetch(api: API) {
const param = useRef()
const [list, setList] = useState()
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)定，我們在使用 useFectch 的組件中使用如下代碼來驗(yàn)證函數(shù)的引用是否發(fā)生了變化。
useEffect(() => {
console.log('setLoading')
}, [setLoading])驗(yàn)證結(jié)果非常神奇，setLoading 的引用居然非常的穩(wěn)定。但對于此時(shí)的你來說，這并沒有什么值得奇怪的地方。因?yàn)樗侵苯訌?useState 中獲取出來的。useState 本身就具備記憶能力，因此對于 setLoading 來說，我們不再需要想任何辦法來讓他的引用來保持穩(wěn)定。
setParam 跟預(yù)期一樣，一點(diǎn)也不穩(wěn)定，每次狀態(tài)變化，他的引用都會發(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 的引用白考慮了。
然后你又看了一眼 setParam 的使用，還是這么個(gè)情況。
setParam(e.target.value)}
/>最后一想，發(fā)現(xiàn)好像 useCallback 又做了無用功。
至此，你徹底悟了。
就說總有一種不確定感，原來少考慮了一步。當(dāng)自定義 hook 傳出來的 函數(shù)在執(zhí)行時(shí)需要傳入?yún)?shù)時(shí)，就不得不在這個(gè)函數(shù)外面包一層匿名函數(shù)，再傳遞給子組件使用，如果它不需要參數(shù)，useCallback 才會發(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()
...
當(dāng)真是真是步步驚心啊。
你終于悟到了要結(jié)合實(shí)際使用的場景去考慮使用 useCallback 的準(zhǔn)確時(shí)機(jī)，自此，融匯貫通成就達(dá)成。
標(biāo)題名稱：useCallback使用的四個(gè)階段，你都知道嗎？
轉(zhuǎn)載注明：http://www.dlmjj.cn/article/dppgcsp.html
