为什么使用getDerivedStateFromProps而不是componentDidUpdate？

Question

正如在这个React Github问题中所读到的,我看到越来越多

成本render()相对较小

在React 16.3中,我想知道为什么会使用新的getDerivedStateFromProps而不是componentDidUpdate？

想象一下这个例子:

getDerivedStateFromProps(nextProps, prevState) {
  if (!prevState.isModalOpen && nextProps.isReady) {
       return { isModalOpen: true };
  }
}

与

componentDidUpdate(prevProps, prevState) {
  if (!prevState.isModalOpen && this.props.isReady) {
        this.setState({ isModalOpen: true });
  }
}

后者似乎更简单,因为它只使用现有的API,看起来就像我们以前在componentWillReceiveProps中做的那样,所以我不明白为什么用户会选择getDerivedStateFromProps？有什么好处？

谢谢!

Answer 1

因此,丹·阿布拉莫夫在Twitter上回答,看起来有两个原因你应该使用getDerivedStateFromProps而不是componentDidUpdate+ setState:

componentDidUpdate中的setState会导致额外的渲染(用户无法直接察觉,但会降低您的应用速度).而你渲染方法不能假设状态已准备好(因为它不会是第一次).

• 表现原因:它避免了不必要的重新渲染.
• 正如getDerivedStateFromProps在init上渲染之前调用的那样,您可以在此函数中初始化状态,而不是使用构造函数来执行此操作.目前,您必须拥有构造函数或componentWillMount在初始渲染之前初始化您的状态.

Answer 2

getDerivedStateFromProps实际上是替代componentWillReceiveProps并且componentDidMount不会被弃用。

\n\n

我很确定是社区决定使用该名称创建静态方法。

\n\n

进行此更改的原因是，这componentWillReceiveProps是导致混乱并进一步导致用户应用程序中的一些内存泄漏的方法之一：

\n\n

\n

其中许多问题因组件生命周期的子集（componentWillMount、componentWillReceiveProps 和 componentWillUpdate）而加剧。这些也恰好是在 React 社区中引起最混乱的生命周期。出于这些原因，我们将弃用这些方法，转而采用更好的替代方法。

\n

\n\n

这是丹·阿布拉莫夫的推文，也使这一点更加明确：

\n\n

\n

然而，这意味着我们\xe2\x80\x99将与17中的\n componentWillReceiveProps()分道扬镳。我们认为 getDerivedStateFromProps()\n 可以更好地完成同样的工作，并且不会那么混乱。也有可能 cWRP() 确实打乱了我们可能正在管道中的数据获取功能的计划。

\n

\n