IT技术 - 为什么使用 getDerivedStateFromProps 而不是 componentDidUpdate？ - 吾爱随笔录

IT技术 reactjs

2021-05-23 07:26:14

正如在这个 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？有什么好处？

谢谢！

2个回答

所以丹·阿布拉莫夫在 Twitter 上回答了，似乎有两个原因你应该使用getDerivedStateFromProps而不是componentDidUpdate+ setState：

componentDidUpdate 中的 setState 会导致额外的渲染（用户无法直接感知，但会减慢您的应用程序的速度）。并且您的渲染方法不能假设状态已准备好（因为它不会是第一次）。

性能原因：它避免了不必要的重新渲染。
正如getDerivedStateFromProps在 init 上渲染之前调用的那样，您可以在此函数中初始化您的状态，而不是让构造函数这样做。目前，您必须有一个构造函数或componentWillMount在初始渲染之前初始化您的状态。

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

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

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

这是丹·阿布拉莫夫的推文，它也更清楚地说明了这一点：

然而，这意味着我们将在 17 中与 componentWillReceiveProps() 分道扬镳。我们认为 getDerivedStateFromProps() 可以更好地完成同样的工作并且不那么令人困惑。碰巧的是，cWRP() 确实打乱了我们可能正在管道中的数据获取功能的计划。🙂

其它你可能感兴趣的问题