通过shouldComponentUpdate对无状态功能组件进行优化 [英] React optimization of stateless, functional components through shouldComponentUpdate

问题描述

我知道React优化的一个关键点是使用 shouldComponentUpdate（）生命周期钩子来检查当前状态/道具对下一个/州道具。

I know that a key point of optimization for React is by using shouldComponentUpdate() lifecycle hook to check the current state/props against the next/state props.

如果我正在构建一个使用大多数功能组件的React应用程序，而不是基于类的有状态组件（可以访问生命周期钩子），我是否放弃了这种特殊的优化？我可以在功能组件内执行类似的检查吗？

If I'm building a React application using mostly functional components, rather than class-based, stateful components (that have access to lifecycle hooks), do I forego this particular optimization? Can I perform a similar check inside of a functional component?

推荐答案

无状态组件是未来优化的候选者，文档提示在没有详细说明的情况下：

Stateless components are candidates for optimization in the future and the docs hint at it without going into details:

在理想的世界中，你的大部分组件都是无状态功能，因为将来我们也会通过避免不必要的检查和内存分配，能够对这些组件进行特定的性能优化。这是推荐的模式，如果可能的话。

In an ideal world, most of your components would be stateless functions because in the future we’ll also be able to make performance optimizations specific to these components by avoiding unnecessary checks and memory allocations. This is the recommended pattern, when possible.

Source

目前，无状态组件不会如果道具未更改，则跳过渲染过程来优化性能。这已得到反应团队成员的确认：

Currently however, stateless components do not optimize performance by skipping the render process if the props are unchanged. This has been confirmed by a member of the react team:

对于复杂组件，定义 shouldComponentUpdate （例如，纯渲染）通常会超过无状态组件的性能优势。文档中的句子暗示了我们计划的一些未来优化，因此我们不会为无状态功能组件分配内部实例（我们将只调用该函数）。我们也可能不会继续持有道具等。微小的优化。我们不讨论文档中的细节，因为优化实际上还没有实现（无状态组件打开了这些优化的大门）。

For complex components, defining shouldComponentUpdate (eg. pure render) will generally exceed the performance benefits of stateless components. The sentences in the docs are hinting at some future optimizations that we have planned, whereby we won't allocate an internal instance for stateless functional components (we will just call the function). We also might not keep holding the props, etc. Tiny optimizations. We don't talk about the details in the docs because the optimizations aren't actually implemented yet (stateless components open the doors to these optimizations).

[... ]

有关于你可以在函数上设置或允许它参与的 pureRender 标志的讨论在shouldUpdate生命周期中，但目前尚未实现。目前，无状态函数不能是纯渲染。

There are discussions about having a pureRender flag that you could set on the function, or allowing it to participate in the shouldUpdate lifecycle, but that's currently not implemented. At the moment, stateless functions can not be pure-render.

值得记住的是，有时人们滥用/过度使用纯渲染;它有时可能比再次运行渲染更昂贵，因为你正在迭代道具数组并可能做像字符串比较这样的事情，这对于最终返回true然后继续重新渲染的组件来说只是额外的工作。 PureRender / shouldComponentUpdate 实际上被认为是性能的逃逸舱口，并不一定应该盲目地应用于每个组件。

It is worth keeping in mind that sometimes people abuse/overuse pure-render; it can sometimes be as or more expensive than running the render again, because you're iterating over the array of props and potentially doing things like string compares, which is just extra work for components that ultimately return true and then proceed to rerender anyway. PureRender / shouldComponentUpdate really is considered an escape hatch for performance and is not necessarily something that should be blindly applied to every component.

来源

我从这次讨论中得出的结论是，在某些情况下，对于复杂的组件，可以通过实现来增加性能.digComponentUpdate 与无状态组件相比。另一方面，我会强烈考虑性能优势是否足以超过组件增加的复杂性和更大的占用空间。

My takeaway from this discussion is that in certain cases for complex components, the performance can be increased by implementing shouldComponentUpdate in comparison to stateless components. On the other hand, I would strongly consider whether the performance benefits are significant enough to outweigh the added complexity and bigger footprint of the component.

这篇关于通过shouldComponentUpdate对无状态功能组件进行优化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！