useCallback与简单函数

Question

什么时候我应该使用useCallback，什么时候使用简单的数组函数？还是我不应该用第二种方法？

const MyCompenent = (props) => {
  const handleClick = useCallback(()=>{
    //do stuff
  })
  return(
    <SomeCompnent onClick={handleClick} />
  )
}
// or
const MyCompenent = (props) => {
  return(
    <SomeCompnent onClick={()=> {/*do stuff*/}} />
  )
}

Answer 1

根据文档的说法，

传递一个内联回调和一个依赖项数组。useCallback将返回回调的回忆录版本，只有在某个依赖项已更改时才会进行更改。这在将回调传递到依赖引用相等以防止不必要呈现(例如shouldComponentUpdate)的优化子组件时非常有用。

这意味着，给定一个纯函数和依赖项，对于给定的参数/依赖集，输出将保持不变。因此，它所做的是保存给定集的输出，如果进行了这样的调用，而不是调用实际函数，直接返回先前计算的值。

在您的示例中，您没有传递任何依赖项。因此，它非常类似于一个简单的函数，但有一层额外的包装。

您可以为处理程序使用命名函数或内联函数。但是，我更喜欢有一个命名的函数，因为它可以保持JSX的清洁，并提供了可重用的可能性。

参考文献：

• React的useCallback和useMemo钩子的例子

Answer 2

为了补充Rajesh的好答案，它实际上可以归结为需要对子组件进行多少优化。

在我们部署大型应用程序的经验中(数百万用户)，更重要的性能检查是Profiler (它是在新的React工具中添加了一个漂亮的火焰图)，而不是renders的重呈现，以及网络抓取(IE:不必要的获取、坏的API，或者可以并发运行的获取，而不是后续运行)。

重新渲染！

在某种程度上，许多开发人员痴迷于React的呈现(我相信部分原因在于突出显示呈现的选项)。

事实上，我认为，Facebook对恢复亮点并不感兴趣是因为所说的混乱。

在我们公司，这也发生在一些开发人员身上，他们认为来自某些组件的呈现是瓶颈(在我看来，他们看错了地方)。

但这也是因为缺乏理解，React的呈现可能是非常非常便宜的，这与创建或销毁可能会变得昂贵的节点完全不同。

他们(和许多人一样)错误地认为呈现是在重新创建HTML树，但事实并非如此。

想象一下，在某个时候，有人说我们的大部分组件应该是PureComponents。我们有数百个组件，所以这有点牵强！

我们的团队很少使用PureComponents或ReactMemo，但是我们的大多数容器即使在重载下也能很好地工作。

因此，回到重点，是的，在组件中，我们正在对呈现进行昂贵的计算，但最重要的是，与UX高度耦合，我们决定进行优化。对于日常的Joe和Alice组件，我们信任它们的反应。

注意：也注意到了React的开发模式比生产慢得多。当我在工作中遇到这样的问题时，我感到惊讶，因为有些页面运行缓慢，基准测试是在开发模式下完成的！(由于生产进行得非常顺利，这个问题没有进一步发展)。