React是否保留状态更新的顺序？

Question

我知道React可能会异步和批量地执行状态更新，以进行性能优化。因此，在调用setstate之后，您永远不能相信会更新状态。但是，您是否信任React按照调用setstate时的顺序更新状态

1. 相同的组件？
2. 不同的组件？

class Container extends React.Component {
  constructor(props) {
    super(props);
    this.state = { a: false, b: false };
  }

  render() {
    return <Button onClick={this.handleClick}/>
  }

  handleClick = () => {
    this.setState({ a: true });
    this.setState({ b: true });
  }
}

class SuperContainer extends React.Component {
  constructor(props) {
    super(props);
    this.state = { a: false };
  }

  render() {
    return <Container setParentState={this.setState.bind(this)}/>
  }
}

class Container extends React.Component {
  constructor(props) {
    super(props);
    this.state = { b: false };
  }

  render() {
    return <Button onClick={this.handleClick}/>
  }

  handleClick = () => {
    this.props.setParentState({ a: true });
    this.setState({ b: true });
  }
}

任何有文档支持的答案都是非常感谢的。

Answer 1

我在React工作。

TLDR：

但是您是否可以信任React以调用setState时所需的相同顺序更新状态

null

null

目前(React16及更早版本），默认情况下只批处理React事件处理程序中的更新。有一个不稳定的API来强制在事件处理程序之外进行批处理，以满足极少数情况下的需要。

在以后的版本中（可能是React17和更高版本），React将默认批处理所有更新，因此您不必考虑这个问题。和往常一样，我们将在React博客和发行说明中宣布有关这方面的任何变化。

理解这一点的关键是，无论您在React事件处理程序中调用多少个组件中的setstate()调用多少个组件，它们都只能在事件结束时生成一个重新呈现。这对于大型应用程序中的良好性能至关重要，因为如果子和父在处理click事件时都调用setstate()，您就不想重新呈现子两次。

当我们在批处理结束时重新呈现UI时，this.state对象会更新。因此，如果需要根据以前的状态更新状态（例如增加计数器），则应该使用函数化的setstate(fn)版本来提供以前的状态，而不是从this.state中读取。如果你对此的原因感到好奇，我在这篇评论中对此进行了深入的解释。

在您的示例中，我们不会看到“中间状态”，因为我们位于启用批处理的React事件处理程序中（因为React“知道”我们何时退出该事件）。

但是，在React16和早期版本中，默认情况下在React事件处理程序之外都没有批处理。因此，如果在您的示例中我们有一个AJAX响应处理程序而不是handleClick，那么每个setstate()将在发生时立即处理。在本例中，是的，您将看到一个中间状态：

promise.then(() => {
  // We're not in an event handler, so these are flushed separately.
  this.setState({a: true}); // Re-renders with {a: true, b: false }
  this.setState({b: true}); // Re-renders with {a: true, b: true }
  this.props.setParentState(); // Re-renders the parent
});

promise.then(() => {
  // Forces batching
  ReactDOM.unstable_batchedUpdates(() => {
    this.setState({a: true}); // Doesn't re-render yet
    this.setState({b: true}); // Doesn't re-render yet
    this.props.setParentState(); // Doesn't re-render yet
  });
  // When we exit unstable_batchedUpdates, re-renders once
});

在内部，React事件处理程序都包装在unstable_batchedUpdates中，这就是为什么它们在默认情况下是批处理的。请注意，在unstable_batchedUpdates中包装更新两次没有效果。当我们退出最外层的unstable_batchedUpdates调用时，更新将被刷新。

该API是“不稳定的”，因为我们将在默认情况下启用批处理时删除它。但是，我们不会在次要版本中删除它，所以如果在某些情况下需要在React事件处理程序之外强制批处理，您可以安全地依赖它，直到React17。

总而言之，这是一个令人困惑的主题，因为默认情况下React只在事件处理程序中进行批处理。这将在未来的版本中改变，并且行为将更加直接。但解决办法不是减少批处理，而是在默认情况下增加批处理。这就是我们要做的。