建站
咨詢
售后
建站咨詢
新聞中心
非 React 使用者估計看了都要搖頭啊。一個破回調(diào)函數(shù)的運用，居然能折騰出來這么多事。一大堆文章都在探討如何使用它更合理。事實上確實如此，在 React 獨特的單向數(shù)據(jù)流刷新機制下，對于 useCallback 認知的逐漸深入實際上也代表著對 React 本身這個機制的理解更進一步，因此在你徹底消化 React 刷新機制之前，這個過程中的每一個知識點可能都有巨大的探討空間
成都創(chuàng)新互聯(lián)公司專業(yè)提供四川雅安電信機房服務(wù)，為用戶提供五星數(shù)據(jù)中心、電信、雙線接入解決方案，用戶可自行在線購買四川雅安電信機房服務(wù)，并享受7*24小時金牌售后服務(wù)。
前幾天我的一位學(xué)生跟我探討了一種 useCallback 的用法，他的想法是：當(dāng)我們在封裝開源工具庫時，對自定義 hook 中暴露出來的鉤子函數(shù)使用 useCallback 緩存。因為我們并不確定使用者是否需要一個引用穩(wěn)定的鉤子函數(shù)，他們有可能是需要的，因此用 useCallback 來包一層是有意義的。但是他并不確定這樣的做法是否合適，是否具備較大的正向收益。
那么我就借著這個案例，來跟大家探討一下，我們在 React 進階的過程中，使用 useCallback 的四個階段。
階段一：敬畏
這個時候你還是一個初學(xué)者，對 React 的理解還不夠深刻不夠全面，但是常?？吹轿恼?，或者聽別人說 useCallback 跟性能優(yōu)化有關(guān)，可對于你而言，你并不是非常清楚它跟性能優(yōu)化的具體關(guān)系在哪里，想知道，但不知道或者不夠確定，因此對這個 hook api 有一種敬畏之心，各個論壇里對于 useCallback 的介紹很多很嘲雜，但你不敢隨便用。
因此你很想去看看別人的代碼里，useCallback 是怎么用的，是在什么場景下使用的，但是想要看到別人的代碼也并不容易，因此你可能會在這個階段徘徊。
階段二：懂了
隨著學(xué)習(xí)的深入，你逐漸開始深入理解了 React 的單向數(shù)據(jù)流機制，也對 React 的使用更加熟練，知道 React 經(jīng)常會存在許多 re-render，你終于搞懂了 useCallback 的使用場景，它結(jié)合 React.memo 能夠緩存組件，避免組件的冗余 re-render。
于是你在項目中大量的使用了他們，就像當(dāng)初 PureComponent 一樣，你恨不得每個函數(shù)都用 useCallback 套一層，以確保自己的項目能最大限度減少 re-render，從而達到一個極致的性能體驗。
function App() {
...
const clickHankler = useCallback(() => {
...
}, [count])
const onOpen = useCallback(() => {
...
}, [])
...
}但是不管你用還不用，是大量使用還是大量不使用，從頁面的運行結(jié)果中，都看不出來你這樣寫帶來了什么實質(zhì)的提升，甚至你有可能在依賴項的使用上感到難受，因為閉包的影響導(dǎo)致實際運行結(jié)果跟你預(yù)想的有出入。但是你能明確感受到 re-render 次數(shù)減少了。因此這個階段你非常堅信自己達到了性能優(yōu)化的目的。
直到一次偶然的面試中，你被面試官一個問題問得啞口無言：只用 useCallback 能達到減少 re-render 的次數(shù)嗎？為什么？
階段三：精通
聽了我的直播分享，徹底搞懂了 React 的底層 DIFF 機制，你發(fā)現(xiàn)原來在 React 底層機制的邏輯下，我們大量的緩存工作其實是沒有必要的。React.memo 也有不小的使用成本，有的時候他的損耗不一定比 re-render 更低，于是你懂得了如何在項目中合理的使用 useCallback + React.memo，一通優(yōu)化下來，項目里的 useCallback 都被刪得差不多了，只在關(guān)鍵位置剩下幾個。
優(yōu)化的結(jié)果很理想，re-render 的情況不僅沒有變多，項目還減負了，性能又得到了提升，你很開心很有成就感。心想我終于又有了成長，再次遇到上次那個面試官，我必定能吊打他。
階段四：貫通
你終于明白了 useCallback 只是一個非常普通的記憶函數(shù)。在 React hooks 特定的機制下記憶函數(shù)本身就被大量運用。React 的許多 hook 都有類似的記憶能力，useCallback 只是最普通的那一個，另外的 hook 都在記憶能力的基礎(chǔ)之上又添加了一些別的語義。
useState
useEffect
useLayoutEffect
useCallback
useMemo
useRef
useReducer
useSyncExternalStore
...這個階段你不再特殊看待他，在你的知識結(jié)構(gòu)里面你也不再特意的把他跟性能優(yōu)化掛上勾，而是把他標(biāo)記為一個記憶函數(shù)，他能夠保持一個函數(shù)的引用，當(dāng)你在 React 這個不穩(wěn)定的上下文環(huán)境中過，需要一個穩(wěn)定的引用時，你才會使用 useCallback。
因此，當(dāng)你在封裝一個開源工具庫時，你想到了你會對外拋出一個鉤子函數(shù)，但是你并不確定使用者會如何使用這個鉤子函數(shù)，使用者有可能會把他傳遞給子組件，此時如果鉤子函數(shù)引用不穩(wěn)，那么就有可能導(dǎo)致子組件 re-render。
例如在我們前面學(xué)習(xí)自定義 hook 的文章中，我們封裝了一個 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
}
}
我們可以看到代碼里，在這個自定義 hook 中，返回了兩個鉤子函數(shù) setLoading setParam。
為了驗證他們的引用是否穩(wěn)定，我們在使用 useFectch 的組件中使用如下代碼來驗證函數(shù)的引用是否發(fā)生了變化。
useEffect(() => {
console.log('setLoading')
}, [setLoading])驗證結(jié)果非常神奇，setLoading 的引用居然非常的穩(wěn)定。但對于此時的你來說，這并沒有什么值得奇怪的地方。因為他是直接從 useState 中獲取出來的。useState 本身就具備記憶能力，因此對于 setLoading 來說，我們不再需要想任何辦法來讓他的引用來保持穩(wěn)定。
setParam 跟預(yù)期一樣，一點也不穩(wěn)定，每次狀態(tài)變化，他的引用都會發(fā)生變化。因為在定義它的時候，每次都是新生成的函數(shù)給他賦值。
return {
param,
+ setParam: (p: P) => param.current = p,
list,
error,
loading,
setLoading
}此時到了 useCallback 大展身手的時候了，我們使用 useCallback 包一層。
return {
param,
- setParam: (p: P) => param.current = p,
+ setParam: useCallback((p: P) => param.current = p, []),
list,
error,
loading,
setLoading
}再次驗證，發(fā)現(xiàn)引用果然變穩(wěn)定了。nice。
但是你害怕這樣做有什么你沒想到的點，因為 useCallback 太善變了，所以你就跑來跟我溝通，想確定一下這樣子做到底能不能帶來很大的正向收益。
萬萬沒想到，我一開口就說：沒必要。
我引導(dǎo)你去看一下引用穩(wěn)定的 setLoading 是如何使用的，你就去翻了一下代碼，結(jié)果一看，壞事了，setLoading 因為傳了一個參數(shù)，導(dǎo)致在使用的時候又套了一層函數(shù)。
代碼如下。此時 onClick 接收到的還是一個引用不穩(wěn)定的匿名函數(shù)... setLoading 的引用白考慮了。
然后你又看了一眼 setParam 的使用，還是這么個情況。
setParam(e.target.value)}
/>最后一想，發(fā)現(xiàn)好像 useCallback 又做了無用功。
至此，你徹底悟了。
就說總有一種不確定感，原來少考慮了一步。當(dāng)自定義 hook 傳出來的 函數(shù)在執(zhí)行時需要傳入?yún)?shù)時，就不得不在這個函數(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é)合實際使用的場景去考慮使用 useCallback 的準(zhǔn)確時機，自此，融匯貫通成就達成。
標(biāo)題名稱：useCallback使用的四個階段，你都知道嗎？
網(wǎng)頁鏈接：http://www.5511xx.com/article/dppgcsp.html
