在使用React Hooks的过程中，作者发现过渡频繁的应用useMemo用会影响程序的性能。在本文中作者将与大家分享如何避免过度使用useMemo，使程序远离性能问题。

经过观察总结，我发现在两种情况下useMemo要么没什么用，要么就是用得太多了，而且可能会影响应用程序的性能表现。

第一种情况很容易就能推断出来，但是第二种情况就比较隐蔽了，很容易被忽略。如果你在生产环境的应用程序中使用了Hook，那么你就可能会在这两个场景中使用useMemo Hook。

下面我就会谈一谈为什么这些useMemo没什么必要，甚至可能影响你的应用性能。此外我会教大家在这些场景中避免过度使用useMemo的方法。

我们开始吧。

不需要useMemo的情况

为了方便，我们把这两类场景分别称为狮子和变色龙。

先不用纠结为什么这么叫，继续读下去就是。

当你撞上一头雄狮，你的第一反应就是撒丫子跑，不要成为狮子的盘中餐，然后活下来跟别人吹牛。这时候可没空思考那么多。

这就是场景A。它们是狮子，你应该下意识地躲开它们。

但在谈论它们之前，我们先来看看更隐蔽的变色龙场景。

相同的引用和开销不大的操作

参考下面的示例组件：

/** 
  @param {number} page 
  @param {string} type 
**/
const myComponent({page, type}) { 
  const resolvedValue = useMemo(() => {
     getResolvedValue(page, type)
  }, [page, type])

  return <ExpensiveComponent resolvedValue={resolvedValue}/> 
}

如上所示，显然作者使用了useMemo。这里他们的思路是，当对resolvedValue的引用出现更改时，他们不想重新渲染ExpensiveComponent。

虽说这个担忧是正确的，但无论何时要用useMemo之前都应该考虑两个问题。

首先，传递给useMemo的函数开销大不大？在上面这个示例中就是要考虑getResolvedValue的开销大不大？JavaScript数据类型的大多数方法都是优化过的，例如Array.map、Object.getOwnPropertyNames()等。如果你执行的操作开销不大（想想大O符号），那么你就不需要记住返回值。使用useMemo的成本可能会超过重新评估该函数的成本。
其次，给定相同的输入值时，对记忆（memoized）值的引用是否会发生变化？例如在上面的代码块中，如果page为2，type为“GET”，那么对resolvedValue的引用是否会变化？简单的回答是考虑resolvedValue变量的数据类型。如果resolvedValue是原始值（如字符串、数字、布尔值、空值、未定义或符号），则引用就不会变化。也就是说ExpensiveComponent不会被重新渲染。

修正过的代码如下：

/** 
  @param {number} page 
  @param {string} type 
**/
const MyComponent({page, type}) {
  const resolvedValue = getResolvedValue(page, type)
  return <ExpensiveComponent resolvedValue={resolvedValue}/> 
}

如前所述，如果resolvedValue返回一个字符串之类的原始值，并且getResolvedValue这个操作的开销没那么大，那么这段代码就非常合理，效率够高了。

只要page和type是一样的，比如说没有prop更改，resolvedValue的引用就会保持不变，只是返回的值不是原始值了（例如变成了对象或数组）。

记住这两个问题：要记住的函数开销很大吗，返回的值是原始值吗？每次都思考这两个问题的话，你就能随时判断使用useMemo是否合适。

出于多种原因需要记住默认状态

参考以下代码块：

/** 
  @param {number} page 
  @param {string} type 
**/
const myComponent({page, type}) { 
  const defaultState = useMemo(() => ({
    fetched: someOperationValue(),
    type: type
  }), [type])

  const [state, setState] = useState(defaultState);
  return <ExpensiveComponent /> 
}

有人会觉得上面的代码没什么问题，但这里useMemo调用肯定是没什么意义的。

首先我们来试着理解一下这段代码背后的思想。作者的思路很不错。当type prop更改时他们需要新的defaultState对象，并且不希望在每次重新渲染时都引用defaultState对象。

虽说这些问题都很实际，但这种方法是错误的，违反了一个基本原则：useState是不会在每次重新渲染时都重新初始化的，只有在组件重载时才会初始化。

传递给useState的参数改名为INITIAL_STATE更合理。它只在组件刚加载时计算（或触发）一次。

useState(INITIAL_STATE)

虽然作者担心在useMemo的type数组依赖项发生更改时获取新的defaultState值，但这是错误的判断，因为useState忽略了新计算的defaultState对象。

懒惰初始化useState时也是一样的道理，如下所示：

/**
   @param {number} page 
   @param {string} type 
**/
const myComponent({page, type}) {
  // default state initializer 
  const defaultState = () => {
    console.log("default state computed")
    return {
       fetched: someOperationValue(),
       type: type
    }
  }

  const [state, setState] = useState(defaultState);
  return <ExpensiveComponent /> 
}

在上面的示例中，defaultState初始函数只会在加载时调用一次。这个函数不会在每次重新渲染时再被调用。因此“默认状态计算”这条日志只会出现一次，除非组件又重载了。

上面的代码改成这样：

/**
   @param {number} page 
   @param {string} type 
**/
const myComponent({page, type}) {
  const defaultState = () => ({
     fetched: someOperationValue(),
     type,
   })

  const [state, setState] = useState(defaultState);

  // if you really need to update state based on prop change, 
  // do so here
  // pseudo code - if(previousProp !== prop){setState(newStateValue)}

  return <ExpensiveComponent /> 
}

下面来谈一些更隐蔽的场景。

把useMemo当作ESLint Hook警告的救命稻草

看看这些评论就能知道，人们在想方设法避免官方的ESLint Hooks插件发出lint警告。我也很理解他们的困境。

我同意Dan Abramov的观点。遏制插件中的eslint-warnings可能会在将来某天付出相应的代价。

一般来说，我认为我们不应该在生产环境的应用程序中遏制这些警告，这样做的话将来就更有可能出现一些隐蔽的错误。

话虽如此，有些情况下我们还是想要遏制这些lint警告。以下是我遇到的一个例子。这里的代码是简化过的，方便理解：

function Example ({ impressionTracker, propA, propB, propC }) {
  useEffect(() => {
    // 追踪初始展示
    impressionTracker(propA, propB, propC)
  }, [])

  return <BeautifulComponent propA={propA} propB={propB} propC={propC} />                 
}

这是一个相当棘手的问题。

在上面这个场景中你不关心props是否改变。你只想用随便哪个初始props调用track函数。这就是展示跟踪（impression tracking）的工作机制。你只能在组件加载时调用展示跟踪函数。这里的区别是你需要使用一些初始props调用该函数。

你可能会想只要简单地将props重命名为initialProps之类的东西就能解决问题了，但这是行不通的。这是因为BeautifulComponent也需要接收更新的prop值。

在这个示例中，你将收到lint警告消息：“React Hook useEffect缺少依赖项：‘impressionTracker’、‘propA’、‘propB’和’propC’。可以包含它们或删除依赖数组。“

这条消息语气很让人不爽，但linter也只是在做自己的工作而已。简单的解决方案是使用eslint-disable注释，但这种方法不见得是最合适的，因为将来你可能在同一个useEffect调用中引入错误。

useEffect(() => {
  impressionTracker(propA, propB, propC)
  // eslint-disable-next-line react-hooks/exhaustive-deps
}, [])

我的建议是使用useRef Hook来保持对不需要更新的初始prop值的引用。

function Example({impressionTracker, propA, propB, propC}) {
  // 保持对初始值的引用     
  const initialTrackingValues = useRef({
      tracker: impressionTracker, 
      params: {
        propA, 
        propB, 
        propC, 
    }
  })

  // 展示跟踪
  useEffect(() => {
    const { tracker, params } = initialTrackingValues.current;
    tracker(params)
  }, []) // 对tracker或params没有ESLint警告

  return <BeautifulComponent propA={propA} propB={propB} propC={propC} />   
}

根据我的测试，在这些情况下linter只会考虑useRef。使用useRef后，linter就明白引用的值不会改变，因此你不会收到任何警告！哪怕你用useMemo也逃不开这些警告的。

例如：

function Example({impressionTracker, propA, propB, propC}) {

  // useMemo记住这个值，使它保持不变
  const initialTrackingValues = useMemo({
    tracker: impressionTracker, 
    params: {
       propA, 
       propB, 
       propC, 
    }
  }, []) //  这里出现lint警告

  // 展示跟踪
  useEffect(() => {
    const { tracker, params} = initialTrackingValues
    tracker(params)
  }, [tracker, params]) //  这些依赖项必须放在这里

  return <BeautifulComponent propA={propA} propB={propB} propC={propC} />
}

上面这个方案就是错误的，即使我用useMemo记忆初始prop值来跟踪初始值，最后还是无济于事。在useEffect调用中，记忆值tracker和params仍然必须作为数组依赖项输入。

有些人就会这样用useMemo，这种用法不对，应该避免。我们应该使用useRef Hook，如前所述。

总而言之，如果你真的想要消除lint警告的话，你会发现useRef是你的好朋友。

useMemo只用于引用相等

很多人都喜欢使用useMemo来处理开销较大的计算并保持引用相等。我同意第一条但不同意第二条。useMemo Hook不应该只用于引用相等。只有一种情况下可以这样做，稍后会提到。

为什么useMemo只用于引用相等是不对的呢？人们不都是这么做的吗？

参考下面的示例：

function Bla() {
  const baz = useMemo(() => [1, 2, 3], [])
  return <Foo baz={baz} />
}

在组件Bla中，baz值之所以被记忆不是因为对数组[1,2,3]的评估开销很大，而是因为对baz变量的引用在每次重新渲染时都会改变。

虽然这看起来不是个问题，但我认为这里不应该使用useMemo这个Hook。

首先，我们看看数组依赖。

useMemo(() => [1, 2, 3], [])

这里，一个空数组被传递给useMemo Hook。也就是说值[1,2,3]仅计算一次——也就是组件加载的时候。

因此我们得出：被记忆的值计算开销并不大，并且在加载之后不会重新计算。

出现这种情况时，希望你能重新考虑要不要用useMemo Hook。你正在记忆一个不是计算开销并不大的值，它将来也不会重新计算。这不符合“memoization”一词的定义。

这个useMemo Hook的用法大错特错。它在语义上就错了，而且会消耗更多内存和计算资源。

那你该怎么办？

首先，作者在这里究竟想要做什么？他们不是要记住一个值；相反，他们希望在重新渲染时保持对值的引用不变。

别让那条黏糊糊的变色龙钻了空子。在这种情况下请使用useRef Hook。

例如，如果你真的讨厌使用当前属性（就像我的很多同事一样），那么只需解构并重命名即可，如下所示：

function Bla() {
  const { current: baz } = useRef([1, 2, 3])
  return <Foo baz={baz} />
}

问题解决了。

实际上，你可以使用useRef来保持对开销较大的函数评估的引用——只要该函数不需要在props更改时重新计算就没问题。

在这些情况下useRef才是正确的Hook，useMemo Hook不合适。

使用useRef Hook来模仿实例变量是Hook的强大武库中用的最少的武器之一。useRef Hook能做的事情远不止保持对DOM节点的引用。尽情拥抱它吧。

请记住这里的条件，不要只为了保持一致的引用就记忆一个值。如果你需要根据更改的prop或值重新计算该值，那就请随意使用useMemo Hook。在某些情况下你仍然可以使用useRef——但是给定数组依赖列表时useMemo最方便。

总结

远离狮子，也不要让变色龙钻了你的空子。如果你放进来变色龙，它们就会改变自己的肤色，融入你的代码库，影响你的代码质量。别给它们机会。

英文原文：https://blog.logrocket.com/rethinking-hooks-memoization/?from=singlemessage&isappinstalled=0

创作场景

不要再滥用 useMemo 了！你应该重新思考 Hooks memoization