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

Question

我知道React可以异步执行批处理状态更新以优化性能。因此，在调用之后，您将永远无法相信要更新的状态setState。但是你可以信任的反应更新相同的顺序状态setState被称为对相同的组件？不同的组件？考虑在以下示例中单击按钮：1.在以下情况下，是否有可能a为假而b为真：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 });  }}2.在以下情况下，是否有可能a为假而b为真：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 });  }}请记住，这些是我用例的极端简化。我意识到我可以以不同的方式进行操作，例如，在示例1中同时更新两个状态参数，以及在示例2中的第一个状态更新的回调中执行第二个状态更新。但是，这不是我的问题，我只对React是否有明确定义的方式来执行这些状态更新感兴趣，仅此而已。非常感谢文档支持的任何答案。

Answer 1

我在做React。

TLDR：

但是你可以相信React可以按照要求setState的顺序更新状态吗

相同的组件？

是。

不同的组件？

是。

该订单的更新总是尊重。是否在它们之间看到中间状态取决于您是否在批处理中。

当前（React 16和更早版本），默认情况下仅批处理React事件处理程序中的更新。有一个不稳定的API可以在极少数情况下在需要时强制在事件处理程序之外进行批处理。

在未来的版本中（可能是React 17及更高版本），React默认会批处理所有更新，因此您无需考虑这一点。与往常一样，我们将在React博客和发行说明中宣布对此所做的任何更改。

理解这一点的关键是，无论setState()您在React事件处理程序中执行了多少个组件中的多少次调用，它们都将在事件结束时仅产生一次重新渲染。这对于大型应用程序性能良好至关重要的，因为如果Child与Parent每个呼叫setState()处理click事件的时候，你不想重新渲染Child两次。

在您的两个示例中，setState()调用都在React事件处理程序中进行。因此，它们总是在事件结束时一起刷新（并且您看不到中间状态）。

更新总是按照发生的顺序进行浅层合并。因此，如果第一个更新为{a: 10}，第二个为{b: 20}，第三个为{a: 30}，则渲染状态将为{a: 30, b: 20}。对相同状态键的更新（例如，a在我的示例中）总是“获胜”。

this.state当我们在批处理结束时重新呈现UI时，将更新该对象。因此，如果您需要基于先前的状态（例如增加计数器）来更新状态，则应使用setState(fn)为您提供先前状态的功能版本，而不是从中读取this.state。如果您对此原因感到好奇，我会在此评论中对其进行深入解释。

在你的榜样，我们也不会看到“中间状态”，因为我们是一个作出反应事件处理中在启用配料（因为响应“知道”什么时候我们退出该事件）。

但是，在React 16和早期版本中，默认情况下，在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

});

我们意识到，根据您是否在事件处理程序中，行为会有所不同，这很不方便。这将在以后的React版本中更改，该版本默认情况下将批处理所有更新（并提供选择加入的API以同步刷新更改）。在我们切换默认行为（可能在React 17中）之前，有一个可用于强制批处理的API：

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事件处理程序之外强制执行批处理，则可以放心地使用它直到React 17。

综上所述，这是一个令人困惑的话题，因为默认情况下，React仅在事件处理程序中进行批处理。这将在将来的版本中更改，并且行为将变得更加简单。但是解决方案不是少批处理，而是默认情况下多批处理。那就是我们要做的。

Answer 2

这实际上是一个非常有趣的问题，但答案应该不会太复杂。在媒体上有一篇很棒的文章有答案。

1）如果这样做

this.setState({ a: true });

this.setState({ b: true });

我不认为会出现的情况下a会true和b会false因为配料。

但是，如果b取决于，a则确实可能存在无法获得预期状态的情况。

// assuming this.state = { value: 0 };

this.setState({ value: this.state.value + 1});

this.setState({ value: this.state.value + 1});

this.setState({ value: this.state.value + 1});

处理完所有上述调用后，this.state.value将为1，而不是您期望的3。

这是在文章中提到的： setState accepts a function as its parameter

// assuming this.state = { value: 0 };

this.setState((state) => ({ value: state.value + 1}));

this.setState((state) => ({ value: state.value + 1}));

this.setState((state) => ({ value: state.value + 1}));

这会给我们 this.state.value === 3