Reactmemo 和 useMemo 应该什么时候使用

2023年7月24日 · 阅读需 4 分钟

Full stack development

useMemo 是一个 React Hook，用于在函数组件内部记忆化一个值。当其依赖项改变时，它会重新计算这个值；否则，它会返回上一次计算的值。这可以帮助我们避免在每次渲染时进行昂贵的计算。
React.memo 是一个高阶组件，它可以让你控制一个组件何时重新渲染。当一个组件被 React.memo 包装后，只有当它的 props 发生改变时，它才会重新渲染。否则，React 将复用上一次渲染的结果，这可以避免不必要的渲染，提高应用的性能。

这两个功能都是 React 的优化工具，可以帮助我们在保持应用响应性的同时提高性能。但是要注意，他们并不能解决所有的性能问题，且在某些情况下可能会引入额外的性能开销。因此，只有在确定需要进行优化，并且这些工具可以有效地提高性能时，才应该使用他们。

举个例子

当然可以。让我们看一个具体的例子，比如一个简单的列表渲染：

function List({ items }) {
  return (
    <ul>
      {items.map(item => (
        <li key={item.id}>{item.name}</li>
      ))}
    </ul>
  );
}

在这个例子中，List 组件接收一个 items prop，并为每个 item 渲染一个列表项。这个组件非常简单，且性能通常是足够的。

然而，如果我们过度优化，可能会这样做：

const ListItem = React.memo(function ListItem({ item }) {
  return <li>{item.name}</li>;
});

function List({ items }) {
  return (
    <ul>
      {items.map(item => (
        <ListItem key={item.id} item={item} />
      ))}
    </ul>
  );
}

在这个优化的版本中，我们创建了一个新的 ListItem 组件，并用 React.memo 对它进行了包装，以避免不必要的重新渲染。然而，这种优化实际上可能没有带来实质性的性能提升，因为原始版本的性能已经足够好。更糟糕的是，这种优化增加了代码的复杂性和难以理解性，让代码的维护变得更困难。

此外，React.memo 的浅比较可能会导致问题。在这个例子中，如果 item 对象的属性发生了改变，但 item 对象本身的引用没有改变，那么 React.memo 可能会错过这个变化，导致 UI 不正确。

总的来说，在大多数情况下，我们应该遵循 "先让它工作，然后让它更快" 的原则，也就是说，应该首先关注应用的功能和正确性，然后再关注性能。只有当性能真的成为问题时，我们才需要考虑使用 useMemo 或 React.memo 进行优化。

我个人觉得这是不是也和 Java 的若无必要，勿增实体的理念很相似，不仅仅适用于 React 或者 JavaScript，也适用于 Java 和其他许多编程语言。这个原则通常被称为 "YAGNI"，即 "You Aren't Gonna Need It"（你不会需要它）。这个原则告诫我们避免过度设计和过度优化，除非真的有必要。

所以在使用 memo 的时候还是要多考虑是不是符合以下三点

不必要的复杂性：如果你的应用或组件并不遇到性能问题，那么引入 useMemo 或 React.memo 可能会增加不必要的复杂性，让代码更难理解和维护。
过度优化：useMemo 和 React.memo 通过记忆值和避免不必要的渲染来提高性能，但这种记忆化和避免渲染本身也需要一些计算和内存。如果你过度使用这两个工具，可能会引入额外的性能开销。
浅比较：React.memo 通过对 props 进行浅比较来判断是否需要重新渲染。这意味着如果 props 是复杂的对象，并且只是内部的某个属性发生了变化，React.memo 可能无法正确地判断是否需要重新渲染。