容量越大越不壞？24萬塊硬盤故障率報告公布 這些產品零故障
8月5日消息，云存儲服務商Backblaze發布了最新的硬盤故障率報告，年故障率有所上升。Backblaze發布的硬盤季度統計數據，其中包括故障率等重要方面。這些結
非 React 使用者估計看了都要搖頭啊。一個破回調函數的運用，居然能折騰出來這么多事。一大堆文章都在探討如何使用它更合理。事實上確實如此，在 React 獨特的單向數據流刷新機制下，對于 useCallback 認知的逐漸深入實際上也代表著對 React 本身這個機制的理解更進一步，因此在你徹底消化 React 刷新機制之前，這個過程中的每一個知識點可能都有巨大的探討空間
前幾天我的一位學生跟我探討了一種 useCallback 的用法，他的想法是：當我們在封裝開源工具庫時，對自定義 hook 中暴露出來的鉤子函數使用 useCallback 緩存。因為我們并不確定使用者是否需要一個引用穩定的鉤子函數，他們有可能是需要的，因此用 useCallback 來包一層是有意義的。但是他并不確定這樣的做法是否合適，是否具備較大的正向收益。
那么我就借著這個案例，來跟大家探討一下，我們在 React 進階的過程中，使用 useCallback 的四個階段。
這個時候你還是一個初學者，對 React 的理解還不夠深刻不夠全面，但是常常看到文章，或者聽別人說 useCallback 跟性能優化有關，可對于你而言，你并不是非常清楚它跟性能優化的具體關系在哪里，想知道，但不知道或者不夠確定，因此對這個 hook api 有一種敬畏之心，各個論壇里對于 useCallback 的介紹很多很嘲雜，但你不敢隨便用。
因此你很想去看看別人的代碼里，useCallback 是怎么用的，是在什么場景下使用的，但是想要看到別人的代碼也并不容易，因此你可能會在這個階段徘徊。
隨著學習的深入，你逐漸開始深入理解了 React 的單向數據流機制，也對 React 的使用更加熟練，知道 React 經常會存在許多 re-render，你終于搞懂了 useCallback 的使用場景，它結合 React.memo 能夠緩存組件，避免組件的冗余 re-render。
于是你在項目中大量的使用了他們，就像當初 PureComponent 一樣，你恨不得每個函數都用 useCallback 套一層，以確保自己的項目能最大限度減少 re-render，從而達到一個極致的性能體驗。
function App() { ... const clickHankler = useCallback(() => { ... }, [count]) const onOpen = useCallback(() => { ... }, []) ...}但是不管你用還不用，是大量使用還是大量不使用，從頁面的運行結果中，都看不出來你這樣寫帶來了什么實質的提升，甚至你有可能在依賴項的使用上感到難受，因為閉包的影響導致實際運行結果跟你預想的有出入。但是你能明確感受到 re-render 次數減少了。因此這個階段你非常堅信自己達到了性能優化的目的。
直到一次偶然的面試中，你被面試官一個問題問得啞口無言：只用 useCallback 能達到減少 re-render 的次數嗎？為什么？
階段三：精通
聽了我的直播分享，徹底搞懂了 React 的底層 DIFF 機制，你發現原來在 React 底層機制的邏輯下，我們大量的緩存工作其實是沒有必要的。React.memo 也有不小的使用成本，有的時候他的損耗不一定比 re-render 更低，于是你懂得了如何在項目中合理的使用 useCallback + React.memo，一通優化下來，項目里的 useCallback 都被刪得差不多了，只在關鍵位置剩下幾個。
優化的結果很理想，re-render 的情況不僅沒有變多，項目還減負了，性能又得到了提升，你很開心很有成就感。心想我終于又有了成長，再次遇到上次那個面試官，我必定能吊打他。
階段四：貫通
你終于明白了 useCallback 只是一個非常普通的記憶函數。在 React hooks 特定的機制下記憶函數本身就被大量運用。React 的許多 hook 都有類似的記憶能力，useCallback 只是最普通的那一個，另外的 hook 都在記憶能力的基礎之上又添加了一些別的語義。
useStateuseEffectuseLayoutEffectuseCallbackuseMemouseRefuseReduceruseSyncExternalStore...這個階段你不再特殊看待他，在你的知識結構里面你也不再特意的把他跟性能優化掛上勾，而是把他標記為一個記憶函數，他能夠保持一個函數的引用，當你在 React 這個不穩定的上下文環境中過，需要一個穩定的引用時，你才會使用 useCallback。
因此，當你在封裝一個開源工具庫時，你想到了你會對外拋出一個鉤子函數，但是你并不確定使用者會如何使用這個鉤子函數，使用者有可能會把他傳遞給子組件，此時如果鉤子函數引用不穩，那么就有可能導致子組件 re-render。
例如在我們前面學習自定義 hook 的文章中，我們封裝了一個 hook useFetch，代碼如下：
import { useState, useRef, useLayoutEffect } from 'react'type API<T, P> = (param?: P) => Promise<T>export default function useFetch<T, P>(api: API<T, P>) { const param = useRef<P>() const [list, setList] = useState<T>() 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 中，返回了兩個鉤子函數 setLoading setParam。
為了驗證他們的引用是否穩定，我們在使用 useFectch 的組件中使用如下代碼來驗證函數的引用是否發生了變化。
useEffect(() => { console.log('setLoading')}, [setLoading])驗證結果非常神奇，setLoading 的引用居然非常的穩定。但對于此時的你來說，這并沒有什么值得奇怪的地方。因為他是直接從 useState 中獲取出來的。useState 本身就具備記憶能力，因此對于 setLoading 來說，我們不再需要想任何辦法來讓他的引用來保持穩定。
setParam 跟預期一樣，一點也不穩定，每次狀態變化，他的引用都會發生變化。因為在定義它的時候，每次都是新生成的函數給他賦值。
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 }再次驗證，發現引用果然變穩定了。nice。
但是你害怕這樣做有什么你沒想到的點，因為 useCallback 太善變了，所以你就跑來跟我溝通，想確定一下這樣子做到底能不能帶來很大的正向收益。
萬萬沒想到，我一開口就說：沒必要。
我引導你去看一下引用穩定的 setLoading 是如何使用的，你就去翻了一下代碼，結果一看，壞事了，setLoading 因為傳了一個參數，導致在使用的時候又套了一層函數。
代碼如下。此時 onClick 接收到的還是一個引用不穩定的匿名函數... setLoading 的引用白考慮了。
<Button className={s.button} onClick={() => setLoading(true)}>然后你又看了一眼 setParam 的使用，還是這么個情況。
<input className={s.input} placeholder="請輸入您要搜索的內容" onChange={(e) => setParam(e.target.value)}/>最后一想，發現好像 useCallback 又做了無用功。
至此，你徹底悟了。
就說總有一種不確定感，原來少考慮了一步。當自定義 hook 傳出來的 函數在執行時需要傳入參數時，就不得不在這個函數外面包一層匿名函數，再傳遞給子組件使用，如果它不需要參數，useCallback 才會發揮它的效果。
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()... <Child onBack={goBack} />當真是真是步步驚心啊。
你終于悟到了要結合實際使用的場景去考慮使用 useCallback 的準確時機，自此，融匯貫通成就達成。
本文鏈接：http://www.www897cc.com/showinfo-26-64102-0.htmluseCallback 使用的四個階段，你都知道嗎？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 掌握Python八種繪圖類型帶你深入時間序列數據分析
下一篇： 2024年不容錯過的十個開發框架
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號