javascript - 为什么 getDerivedStateFromProps 是静态方法？

Question

我还没有研究静态 getDerivedStateFromProps，所以我试图了解它。

我知道 React 通过引入一个名为 static getDerivedStateFromProps() 的新生命周期方法在 React v16+ 中弃用了 componentWillReceiveProps。好的，但想知道为什么 React 已更改为静态方法而不是普通方法。

为什么

   static getDerivedStateFromProps(nextProps, prevState){

   }

为什么不

   getDerivedStateFromProps(nextProps, prevState){

   }

我无法理解为什么它是静态方法。

Answer 1

要了解 React 试图通过静态方法实现什么，您应该很好地理解以下内容:

副作用

为什么异步代码在 componentDidMount 钩子(Hook)之前被认为是不好的方法

异步渲染

静态方法如何帮助阻止不纯和异步编码

副作用只不过是在范围之外操纵任何数据。因此，getDerivedStateFromProps 中的副作用将意味着对其自身局部变量以外的任何其他变量的更改。

不会引起副作用的函数称为纯函数，对于它们的参数，它们在被操作之前被克隆，从而保留这些参数指向的对象的状态。

这些函数只是从它们的范围内返回修改后的值，调用者可以用返回的数据决定操作过程。

在像 React 这样的库中引入自定义异步代码并使用自己的生命周期流并不是一个好主意。 它应该在适当的时候小心地插入。让我们通过分析自定义类组件的组件创建生命周期来理解为什么(为了保持简短，让我们考虑它也是根元素)。

一开始 ReactDOM.render 方法调用 react.createElement() 方法调用。

react.createElement() => 调用 new ClassElement(props) 构造函数 => 返回 ClassElement 实例。

在构造函数调用之后， react.createElement() 调用 ClassElement.getDerivedStateFromProps(props) 方法调用。

上述方法返回后， react.createElement() 调用 instance.render() 方法。

(这个可以跳过)

This is followed up with other synchronous calls such as diffing with virtual DOM and updating real DOM etc and there are no hooks provided to tap into these calls(mostly because there is no strong need). A key point to note here is that javascript execution, real DOM updates and UI painting - all - happen within a single thread in the browser thus forcing them to be synchronous. This is one reason why you can write something synchronous like:

let myDiv = document.getElementbyID("myDiv");
myDiv.style.width = "300px"; // myDiv already holds a reference to the real DOM element
console.log(myDiv.style.width); // the width is already set!

because you know at the end of each of those statements, that the earlier statement is completed in DOM and in browser window(UI I mean).

最后，render 方法返回后，react.createElement() 调用 componentDidMount 成功标记生命周期结束。 既然已经结束，componentDidMount 自然是连接异步和非纯函数的最佳连接点。

我们必须明白的是，生命周期方法出于性能和灵活性的原因不断调整，并且完全在 React 工程师的控制之下。这不仅适用于 React，事实上它适用于任何第三方代码的流程。因此，引入不纯函数或异步调用可能会导致问题，因为您将迫使 React 工程师谨慎进行优化。

例如如果 React 工程师决定在单个生命周期流中运行两次或更多次 getDerivedStateFromProps，那么不纯函数和异步调用都会被触发两次或更多次，直接影响应用程序的某些部分。然而对于纯函数，这不会成为问题，因为它们只返回值，并且由 React 工程师决定在多个 getDerivedStateFromProps 调用中的过程(他们可以简单地丢弃所有返回值直到最后一次调用并利用最后一个)。

另一个例子是，如果 React 工程师决定使渲染调用异步会怎样。 也许他们想要将所有的渲染调用(从父级到所有嵌套的子级)集中起来并异步触发它们以提高性能。

现在这意味着在渲染方法中或在它之前编写的异步调用(如在构造函数或 getDerivedStateFromProps 中)可能会干扰渲染过程，因为异步过程完成的不可预测性。一个可以在另一个之前或之后完成，不可预测地触发它们各自的回调。这种不可预测性可以通过多重渲染、不可预测状态等形式反射(reflect)出来。

重要的是，这两个想法不仅仅是示例，而是由 React 工程师表达为 future 可能的优化方法。在这里阅读: https://stackoverflow.com/a/41612993/923372

尽管如此，React 工程师知道那里的开发人员仍然可以编写异步代码或不纯的函数，为了阻止这种情况，他们将生命周期方法之一设为静态。 构造函数、render、getSnapshotBeforeUpdate、componentDidMount 和 componentDidUpdate 方法不能是静态的，因为它们需要访问实例属性，如 this.state、this.props、其他自定义事件处理程序等(构造函数初始化它们，render 使用它们来控制 UI逻辑，其他生命周期方法需要这些来与早期状态进行比较)

但是，考虑到 getDerivedStateFromProps，如果先前的 props 与当前的 props 不同，则提供此钩子(Hook)仅用于返回状态的更新克隆。根据这个定义，这听起来很纯粹，不需要任何对实例属性的访问。让我们分析一下原因。

为了让这个钩子(Hook)工作，开发者首先需要将之前的 props 存储在实例状态中(比方说，在构造函数调用中)。这是因为 getDerivedStateFromProps 接收实例状态以及新的 props 作为参数。然后，开发人员可以继续比较所需的属性并返回状态的更新克隆(无需访问 this.props 或 this.state)。

通过将 getDerivedStateFromProps 设为静态，React 不仅会强制您编写纯函数，还会使编写异步调用变得困难，因为您无法从该方法中访问任何实例。 通常异步调用会提供一个回调，它很可能是一个实例方法。

现在这并不意味着开发人员不能编写它们，相反，这只是使其变得困难并被迫远离此类方法。

一个简单的经验法则是远离不纯和异步的函数 第三方诱导流量持续时间的方法。 您应该只在此类流程结束时引入此类方法。