函数组件中的 shouldComponentUpdate [英] shouldComponentUpdate in function components
问题描述
我有一个关于 React 的 shouldComponentUpdate(未覆盖时)的问题.我确实更喜欢纯函数组件，但我担心它每次都会更新，即使 props/state 没有改变.所以我正在考虑改用 PureComponent 类.
I have a question regarding React's shouldComponentUpdate (when not overwritten). I do prefer pure, function components, but I am afraid that it updates every time, even though props/state did not change.
So I am considering using the PureComponent class instead.
我的问题是:函数组件是否具有与 PureComponents 相同的 shouldComponentUpdate 检查?还是每次都更新?
My question regarding that:
Do function components have the same shouldComponentUpdate check as PureComponents? Or does it update every time?
推荐答案
在 React 中，函数式组件是无状态的，它们没有生命周期方法.无状态组件是编写 React 组件的一种优雅方式，我们的包中没有太多代码.但在内部，无状态组件被包装在一个类中，当前没有应用任何优化.这意味着无状态和有状态组件在内部具有相同的代码路径(尽管我们对它们的定义不同).
In React, functional components are stateless and they do not have lifecycle methods. Stateless components are an elegant way of writing React components without much code in our bundle. But internally, Stateless components are wrapped in a class without any optimizations currently applied. That means both stateless and stateful components has the same code path internally (although we define them differently).
但是在未来 React 可能会像这里所说的那样优化无状态组件:
But in the future React may optimize stateless components as said it here:
未来，我们还将能够进行性能优化通过避免不必要的检查和内存来特定于这些组件分配.[ 更多阅读... ]
In the future, we’ll also be able to make performance optimizations specific to these components by avoiding unnecessary checks and memory allocations. [ More reading... ]
shouldComponentUpdate
您可以在这里应用我们的自定义优化并避免不必要的组件重新渲染.下面解释了这种方法与不同类型组件的用法:
shouldComponentUpdate
This is where you we can apply our custom optimizations and avoid unnecessary re-rendering of components. The usage of this method with different types of components are explained below:
功能无状态组件
如前所述，无状态组件没有生命周期方法，因此我们无法使用 shouldComponentUpdate 优化它们.但是它们已经以不同的方式进行了优化，它们具有更简单和优雅的代码结构，并且比具有所有生命周期钩子的组件花费更少的字节.
As said before, stateless components do not have life cycle methods thus we cannot optimize them using shouldComponentUpdate. But they are already optimized in a different way, they have much simpler and elegant code structure and costs less bytes than a component with all life-cycle hooks.
扩展 React.PureComponent
从 React v15.3.0 开始，我们有一个名为 PureComponent 的新基类使用 PureRenderMixin 内置扩展.在幕后，这在 shouldComponentUpdate 中使用了当前 props/state 与下一个 props/state 的浅层比较.
From React v15.3.0, we have a new base class called PureComponent
to extend with PureRenderMixin built-in. Under the hood this employs a shallow comparison of current props/state with next props/state within a shouldComponentUpdate.
也就是说，我们仍然不能依赖 PureComponent 类来将我们的组件优化到我们想要的水平.如果我们有 Object 类型(数组、日期、普通对象)的道具，就会发生这种异常情况.这是因为我们在比较对象的时候有这个问题:
That said, we still cannot rely on PureComponent class to get our components optimized to the level we want. This anomaly case happens if we have props with Object types (arrays, dates, plain objects). This is because we have this problem when comparing objects:
const obj1 = { id: 1 };
const obj2 = { id: 1 };
console.log(obj1 === obj2); // prints false
因此，简单的比较不足以确定事情是否发生了变化.但是如果你的 props 只是字符串、数字、布尔值......而不是对象，请使用 PureComponent 类.如果您不想实现自己的自定义优化，也可以使用它.
Hence a shallow comparison won't suffice to determine whether things have changed or not. But use PureComponent class if your props are just string, number, boolean.. and not objects. Also use it if you do not want to implement your own custom optimizations.
扩展 React.Component
考虑上面的例子；如果我们知道如果id 改变了对象也改变了，那么我们可以通过比较obj1.id === obj2.id 来实现我们自己的自定义优化.那就是我们可以扩展我们普通的Component基类，并使用shouldComponentUpdate自己做特定键的比较.
Consider the above example; if we know that the objects have changed if the id has changed, then we can implement our own custom optimization by comparing obj1.id === obj2.id. That is where we can extend our normal Component base class and use shouldComponentUpdate to do the comparison of specific keys by ourselves.
这篇关于函数组件中的 shouldComponentUpdate的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
