React Hooks 最佳实践

在第一帧中，p 标签中的文本为 0。点击 "Delay setCount"，文本依然为 0。随后在 3 秒内连续点击 "setCount" 两次，将会分别执行第二帧和第三帧。你将看到 p 标签中的文本由 0 变化为 1, 2。但在点击 "Delay setCount" 3 秒后，文本重新变为 1。

count，handleClick 都是 Example2 函数作用域中的常量。在点击 "Delay setCount" 时，定时器设置 3000ms 到期后的执行函数为 delayAction_1，函数中读取 count_1 常量的值是 0，这和第二帧的 count_2 无关。

获取过去或未来帧中的值

对于 state，如果想要在第一帧时点击 "Delay setCount" ，在一个异步回调函数的执行中，获取到 count 最新一帧中的值，不妨向 setCount 传入函数作为参数^[3]。

其他情况下，例如需要读取到 state 及其衍生的某个常量，相对于变量声明时所在帧过去或未来的值，就需要使用 useRef，通过它来拥有一个在所有帧中共享的变量。

如果要与 class 组件进行比较，useRef 的作用相对于让你在 class 组件的 this 上追加属性。

在组件的第一帧中，refContainer.current 将被赋予初始值 initialValue，之后便不再发生变化。但你可以自己去设置它的值。设置它的值不会重新触发 render 函数。

例如，我们把第 n 帧的某个 props 或者 state 通过 useRef 进行保存，在第 n + 1 帧可以读取到过去的，第 n 帧中的值。我们也可以在第 n + 1 帧使用 ref 保存某个 props 或者 state，然后在第 n 帧中声明的异步回调函数中读取到它。

在 setCount 后便会执行下一帧，在函数的开头，currentCount 始终与最新的 count state 保持同步。因此，在 setTimeout 中可以通过此方法获取到回调函数执行时当前的 count 值。

这段代码实现的功能是，count 初始值为 1，点击按钮后累加到 2，随后点击按钮，总是用当前 count 的值和前一个 count 的值进行累加，得到新的 count 的值。

prevCountRef 在 render 函数执行的过程中，与最新的 count state 进行了同步。由于在同步前，我们将该 ref 保存到函数作用域下的另一个变量 prevCount 中，因此我们总是能够获取到前一个 count 的值。

同样的方法，我们可以用于保存任何值：某个 prop，某个 state 变量，甚至一个函数等。在后面的 Effects 部分，我们会继续使用 refs 为我们带来好处。

每一帧可以拥有独立的 Effects

如果弄清了前面的『每一帧拥有独立的变量』的概念，你会发现，若某个 useEffect/useLayoutEffect 有且仅有一个函数作为参数，那么每次 render 函数执行时该 Effects 也是独立的。因为它是在 render 函数中选择适当时机的执行。

对于 useEffect 来说，执行的时机是完成所有的 DOM 变更并让浏览器渲染页面后，而 useLayoutEffect 和 class 组件中 componentDidMount, componentDidUpdate一致——在 React 完成 DOM 更新后马上同步调用，会阻塞页面渲染。

如果 useEffect 没有传入第二个参数，那么第一个参数传入的 effect 函数在每次 render 函数执行是都是独立的。每个 effect 函数中捕获的 props 或 state 都来自于那一次的 render 函数。

在这个例子中，每一次对 count 进行改变，重新执行 render 函数后，延迟 3 秒打印 count 的值。

我们发现经过延时后，每个 count 的值被依次打印了，他们从 0 开始依次递增，且不重复。

如果换成 class 组件，尝试使用 componentDidUpdate 去实现，会得到不一样的结果：

this.state.count 总是指向最新的 count 值，而不是属于某次调用 render 函数时的值。

因此，在使用 useEffect 时，应当抛开在 class 组件中关于生命周期的思维。他们并不相同。在 useEffect 中刻意寻找那几个生命周期函数的替代写法，将会陷入僵局，无法充分发挥 useEffect 的能力。

在比对中执行 Effects

React 针对 React Elements 前后值进行对比，只去更新 DOM 真正发生改变的部分。对于 Effects，能否有类似这样的理念呢？

某个 Effects 函数一旦执行，函数内的副作用已经发生，React 无法猜测到函数相比于上一次做了哪些变化。但我们可以给 useEffect 传入第二个参数，作为依赖数组 (deps)，避免 Effects 不必要的重复调用。

如果我们频繁修改 count，每次执行 Effect，上一次的计时器被清除，需要调用 setInterval 重新进入时间队列，实际的定期时间被延后，甚至有可能根本没有机会被执行。

在 Effect 函数中寻找一些变量添加到 deps 中，需要满足条件：其变化时，需要重新触发 effect。

按照这种实践方式，count 变化时，我们并不希望重新 setInterval，故 deps 为空数组。这意味着该 hook 只在组件挂载时运行一次。Effect 中明明依赖了 count，但我们撒谎说它没有依赖，那么当 setInterval 回调函数执行时，获取到的 count 值永远为 0。

遇到这种问题，直接从 deps 移除是不可行的。静下来分析一下，此处为什么要用到 count？能否避免对其直接使用？

可以看到，在 setCount 中用到了 count，为的是把 count 转换为 count + 1 ，然后返回给 React。React 其实已经知道当前的 count，我们需要告知 React 的仅仅是去递增状态，不管它现在具体是什么值。

所以有一个最佳实践：状态变更时，应该通过 setState 的函数形式来代替直接获取当前状态。

在这里，同样的，当count 变化时，我们并不希望重新 setInterval。但我们可以把 count 通过 ref 保存起来。

这样，count 的确不再被使用，而是用 ref 存储了一个在所有帧中共享的变量。

另外的情况是，Effects 依赖了函数或者其他引用类型。与原始数据类型不同的是，在未优化的情况下，每次 render 函数调用时，因为对这些内容的重新创建，其值总是发生了变化，导致 Effects 在使用 deps 的情况下依然会频繁被调用。

对于这个问题，官网的 FAQ^[5] 已经给出了答案：对于函数，使用 useCallback 避免重复创建；对于对象或者数组，则可以使用 useMemo。从而减少 deps 的变化。

使用 ESLint 插件

该插件除了帮你检查使用 Hook 需要遵循的两条规则^[6]外，还会向你提示在使用 useEffect 或者 useMemo 时，deps 应该填入的内容。

如果你正在使用 VSCode，并且安装了 ESLint 扩展。当你编写 useEffect 或者 useMemo ，且 deps 中的内容并不完整时，deps 所在的那一行便会给出警告或者错误的提示，并且会有一个快速修复的功能，该功能会为你自动填入缺失的 deps。

对于这些提示，不要暴力地通过 eslint-disable 禁用。未来，你可能再次修改该 useEffect 或者 useMemo，如果使用了新的依赖并且在 deps 中漏掉了它，便会引发新的问题。有一些场景，比如 useEffect 依赖一个函数，并且填入 deps 了。但是这个函数使用了 useCallback 且 deps 出现了遗漏，这种情况下一旦出现问题，排查的难度会很大，所以为什么要让 ESLint 沉默呢？

尝试用上一节的方法进行分析，对于一些变量不希望引起 effect 重新更新的，使用 ref 解决。对于获取状态用于计算新的状态的，尝试 setState 的函数入参，或者使用 useReducer 整合多个类型的状态。

使用 useMemo/useCallback

useMemo 的含义是，通过一些变量计算得到新的值。通过把这些变量加入依赖 deps，当 deps 中的值均未发生变化时，跳过这次计算。useMemo 中传入的函数，将在 render 函数调用过程被同步调用。

除此以外，useMemo 也非常适合用于存储引用类型的数据，可以传入对象字面量，匿名函数等，甚至是 React Elements。

对于函数，其作为另外一个 useEffect 的 deps 时，减少函数的重新生成，就能减少该 Effect 的调用，甚至避免一些死循环的产生;

对于对象和数组，如果某个子组件使用了它作为 props，减少它的重新生成，就能避免子组件不必要的重复渲染，提升性能。

此时，每当父组件需要 render 时，子组件也会执行 render。如果使用 useMemo 对 data 进行优化：

当父组件 render 时，只要满足 id 不变，data 的值也不会发生变化，子组件也将避免 render。

对于组件返回的 React Elements，我们可以选择性地提取其中一部分 elements，通过 useMemo 进行缓存，也能避免这一部分的重复渲染。

在过去的 class 组件中，我们通过 shouldComponentUpdate 判断当前属性和状态是否和上一次的相同，来避免组件不必要的更新。其中的比较是对于本组件的所有属性和状态而言的，无法根据 shouldComponentUpdate 的返回值来使该组件一部分 elements 更新，另一部分不更新。

为了进一步优化性能，我们会对大组件进行拆分，拆分出的小组件只关心其中一部分属性，从而有更多的机会不去更新。

而函数组件中的 useMemo 其实就可以代替这一部分工作。为了方便理解，我们来看例五：

假设组件，其自身的 render 消耗较多的时间。默认情况下，每次 setCount 改变 count 的值，便会重新对进行 render，其返回的 React Elements 中3个也重新 render，其耗时的操作阻塞了 UI 的渲染。导致按下 "setCount" 按钮后出现了明显的卡顿。

为了优化性能，我们可以将 main 变量这一部分单独作为一个组件

，拆分出去，并对

使用诸如 React.memo , shouldComponentUpdate 的方式，使 count 属性变化时，

不重复 render。

const Main = React.memo((props) => {
    const { foo }= props;
    return (
        
            
                
                
                
                
        
    );
});

而现在，我们可以使用 useMemo，避免了组件拆分，代码也更简洁易懂：

function Example(props) {
    const [count, setCount] = useState(0);
    const [foo] = useState("foo");

    const main = useMemo(() => (
        
            
            
            
            
            
        
    ), [foo]);

    return (
        
            {count}
             setCount(count + 1)}>setCount
            {main}
        
    );
}

惰性初始值

对于 state，其拥有惰性初始化的方法^[7]。可能有人不明白它的作用。

someExpensiveComputation 是一个相对耗时的操作。如果我们直接采用

const initialState = someExpensiveComputation(props);
const [state, setState] = useState(initialState);

注意，虽然 initialState 只在初始化时有其存在的价值，但是 someExpensiveComputation 在每一帧都被调用了。只有当使用惰性初始化的方法：

const [state, setState] = useState(() => {
    const initialState = someExpensiveComputation(props);
    return initialState;
});

因 someExpensiveComputation 运行在一个匿名函数下，该函数当且仅当初始化时被调用，从而优化性能。

我们甚至可以跳出计算 state 这一规定，来完成任何昂贵的初始化操作。

useState(() => {
    someExpensiveComputation(props);
    return null;
});

避免滥用 refs

当 useEffect 的依赖频繁变化，你可能想到把频繁变化的值用 ref 保存起来。然而，useReducer 可能是更好的解决方式：使用 dispatch 消除对一些状态的依赖。官网的 FAQ^[8] 有详细的解释。

最终可以总结出这样的实践：

useEffect 对于函数依赖，尝试将该函数放置在 effect 内，或者使用 useCallback 包裹；useEffect/useCallback/useMemo，对于 state 或者其他属性的依赖，根据 eslint 的提示填入 deps；如果不直接使用 state，只是想修改 state，用 setState 的函数入参方式（setState(c => c + 1)）代替；如果修改 state 的过程依赖了其他属性，尝试将 state 和属性聚合，改写成 useReducer 的形式。当这些方法都不奏效，使用 ref，但是依然要谨慎操作。

避免滥用 useMemo

使用 useMemo 当 deps 不变时，直接返回上一次计算的结果，从而使子组件跳过渲染。

但是当返回的是原始数据类型（如字符串、数字、布尔值）。即使参与了计算，只要 deps 依赖的内容不变，返回结果也很可能是不变的。此时就需要权衡这个计算的时间成本和 useMemo 额外带来的空间成本（缓存上一次的结果）了。

此外，如果 useMemo 的 deps 依赖数组为空，这样做说明你只是希望存储一个值，这个值在重新 render 时永远不会变。

比如：

const Comp = () => {
    const data = useMemo(() => ({ type: 'xxx' }), []);
    return ;
}

可以被替换为：

const Comp = () => {
    const { current: data } = useRef({ type: 'xxx' });
    return ;
}

甚至：

const data = { type: 'xxx' };
const Comp = () => {
    return ;
}

此外，如果 deps 频繁变动，我们也要思考，使用 useMemo 是否有必要。因为 useMemo 占用了额外的空间，还需要在每次 render 时检查 deps 是否变动，反而比不使用 useMemo 开销更大。

受控与非受控

在一个自定义 Hooks，我们可能有这样一段逻辑：

useSomething = (inputCount) => {
    const [ count, setCount ] = setState(inputCount);
};

这里有一个问题，外部传入的 inputCount 属性发生了变化，使其与 useSomething Hook 内的 count state 不一致时，是否想要更新这个 count ？

默认不会更新，因为 useState 参数代表的是初始值，仅在 useSomething 初始时赋值给了 count state。后续 count 的状态将与 inputCount 无关。这种外部无法直接控制 state 的方式，我们称为非受控。

如果想被外部传入的 props 始终控制，比如在这个例子中，useSomething 内部，count 这一 state 的值需要从 inputCount 进行同步，需要这样写：

useSomething = (inputCount) => {
    const [ count, setCount ] = setState(inputCount);
    setCount(inputCount);
};

setCount后，React 会立即退出当前的 render 并用更新后的 state 重新运行 render 函数。这一点，官网文档^[9] 是有说明的。

在这种的机制下，state 由外界同步的同时，内部又有可能通过 setState 来修改 state，可能引发新的问题。例如 useSomething 初始时，count 为 0，后续内部通过 setCount 修改了 count 为 1。当外部函数组件的 render 函数重新调用，也会再一次调用 useSomething，此时传入的 inputCount 依然是 0，就会把 count 变回 0。这很可能不符合预期。

遇到这样的问题，建议将 inputCount 的当前值与上一次的值进行比较，只有确定发生变化时执行 setCount(inputCount) 。

当然，在特殊的场景下，这样的设定也不一定符合需求。官网的这篇文章^[10] 有提出类似的问题。

实践：useSlider

通过一个滑动选择器自定义 hook userSlider 的实现，我们可以回答上面的这个问题，顺便对本文做一个总结。

image

userSlider 需要实现的逻辑是：按住滑动选择器的圆形手柄区域并拖动可以调节数值大小，数值范围为 0 到 1。

userSlider 只负责逻辑的实现，UI 样式由组件自行完成。为了模拟真实业务，另外通过文本展示了当前的数值。并有几个按钮用于切换数值的初始值，这是为了切换分类后，当前的滑动选择器需要重置到某个数值。

按照常规的逻辑，我们实现了以下代码：

Edit useSlider 问题

当前的问题是，useEffect 涉及到多个 state 的获取与计算。导致鼠标按下、移动、弹起的几个操作中因为对 stata 的修改，useEffect 频繁刷新，且涉及到了鼠标按下、移动、弹起事件监听的取消与重新绑定，这带来了性能问题以及较难观察到的 BUG。

和前面的 setInterval 例子相似，我们不希望在状态变动时，刷新 useEffect。由于此处涉及到多个状态：是否滑动中、鼠标位置、上一次鼠标的问题、选择器的可滑动宽度，如果整合到一个 state 中，会面临代码不清晰，缺少内聚性的问题，我们尝试用 useReducer 做一次替换。

const reducer = (state, action) => {
    switch (action.type) {
        case "start":
            return {
                ...state,
                lastPos: action.x,
                slideRange: action.slideWidth,
                sliding: true
            };
        case "move": {
            if (!state.sliding) {
                return state;
            }
            const pos = action.x;
            const delta = pos - state.lastPos;
            return {
                ...state,
                lastPos: pos,
                ratio: fixRatio(state.ratio + delta / state.slideRange)
            };
        }
        case "end": {
            if (!state.sliding) {
                return state;
            }
            const pos = action.x;
            const delta = pos - state.lastPos;
            return {
                ...state,
                lastPos: pos,
                ratio: fixRatio(state.ratio + delta / state.slideRange),
                sliding: false
            };
        }
        default:
            return state;
    }
};

//...

const handleThumbMouseDown = useCallback(ev => {
    const hotArea = hotAreaRef.current;
    dispatch({
        type: "start",
        x: ev.pageX
      slideWidth: hotArea.clientWidth
    });
}, []);

useEffect(() => {
    const onSliding = ev => {
        dispatch({
            type: "move",
            x: ev.pageX
        });
    };
    const onSlideEnd = ev => {
        dispatch({
            type: "end",
            x: ev.pageX
        });
    };
    document.addEventListener("mousemove", onSliding);
    document.addEventListener("mouseup", onSlideEnd);

    return () => {
        document.removeEventListener("mousemove", onSliding);
        document.removeEventListener("mouseup", onSlideEnd);
    };
}, []);

这样处理后，effect 只要执行一次即可。

接下来还有一个问题没有处理，目前 initRatio 是作为初始值传入的，useSlider 内部的 ratio 是不受外部控制的。

以一个音乐均衡器的设置为例：当前滑动选择器代表的是低频端（31）的增益值，用户通过拖动滑块可以设置这个值的大小（-12 到 12 dB 范围，我们设置到了 3 dB）。同时我们提供了一些预设选项，一旦选择预设选项，如『流行』风格，当前滑块需要重置到特定值 -1 dB。为此， useSlider 需要提供控制状态的方法。

image

根据前一节的介绍，在 useSlider 的开头，我们可以将属性 initRatio 的当前值与上一次的值进行比较，若发生变化，则执行 setRatio。但仍然有场景无法满足：用户选择了『流行』这一预设，然后拖动滑块进行了调节，之后又重新选择『流行』这一预设，此时 initRatio 没有任何变化，但我们期望 ratio 重新变为 initRatio。

解决这个问题的办法是，在 useSlider 内部添加一个 setRatio 方法。

const setRatio = useCallback(
    ratio =>
        dispatch({
            type: "setRatio",
            ratio
        }),
    []
);

将该方法输出供外部用于对 ratio 控制。initRatio 不再控制 ratio 的状态，仅用于设置初始值。

可以看下最终的实现方案：

Edit useSlider 最终版

该方案中，除了完成以上需求，还支持在选择器的其他区域点击直接跳转到对应的数值；支持设定选择器为垂直还是水平方向。供大家参考。

结束语

忘掉 class 组件的生命周期，重新审视函数式组件的意义，是用好 React Hooks 的关键一步。希望这篇文章能帮助大家进一步理解并获取到一些最佳实践。当然，不同的 React Hooks 使用姿势可能带来不同的最佳实践，欢迎大家交流。

React Hooks 最佳实践

写在前面

函数式组件

{title}

每一帧拥有独立的变量

Example2

Example