非 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 都在记忆能力的基础之上又添加了一些别的语义。
useState
useEffect
useLayoutEffect
useCallback
useMemo
useRef
useReducer
useSyncExternalStore
...
这个阶段你不再特殊看待他,在你的知识结构里面你也不再特意的把他跟性能优化挂上勾,而是把他标记为一个记忆函数,他能够保持一个函数的引用,当你在 React 这个不稳定的上下文环境中过,需要一个稳定的引用时,你才会使用 useCallback。
因此,当你在封装一个开源工具库时,你想到了你会对外抛出一个钩子函数,但是你并不确定使用者会如何使用这个钩子函数,使用者有可能会把他传递给子组件,此时如果钩子函数引用不稳,那么就有可能导致子组件 re-render。
例如在我们前面学习自定义 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 中,返回了两个钩子函数 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 的引用白考虑了。
setLoading(true)}
>
然后你又看了一眼 setParam 的使用,还是这么个情况。
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()
...
当真是真是步步惊心啊。
你终于悟到了要结合实际使用的场景去考虑使用 useCallback 的准确时机,自此,融汇贯通成就达成。