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

我知道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是否有明确定义的方式来执行这些状态更新感兴趣,仅此而已。


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


喵喔喔
浏览 693回答 3
3回答

慕少森

我在做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(() => {&nbsp; // We're not in an event handler, so these are flushed separately.&nbsp; this.setState({a: true}); // Re-renders with {a: true, b: false }&nbsp; this.setState({b: true}); // Re-renders with {a: true, b: true }&nbsp; this.props.setParentState(); // Re-renders the parent});我们意识到,根据您是否在事件处理程序中,行为会有所不同,这很不方便。这将在以后的React版本中更改,该版本默认情况下将批处理所有更新(并提供选择加入的API以同步刷新更改)。在我们切换默认行为(可能在React 17中)之前,有一个可用于强制批处理的API:promise.then(() => {&nbsp; // Forces batching&nbsp; ReactDOM.unstable_batchedUpdates(() => {&nbsp; &nbsp; this.setState({a: true}); // Doesn't re-render yet&nbsp; &nbsp; this.setState({b: true}); // Doesn't re-render yet&nbsp; &nbsp; this.props.setParentState(); // Doesn't re-render yet&nbsp; });&nbsp; // When we exit unstable_batchedUpdates, re-renders once});内部React事件处理程序都被包装,unstable_batchedUpdates这就是为什么默认情况下对它们进行批处理的原因。请注意,将更新打包unstable_batchedUpdates两次是无效的。当我们退出最外部的unstable_batchedUpdates调用时,将刷新更新。该API是“不稳定的”,即默认情况下启用批处理后我们将其删除。但是,我们不会在次要版本中将其删除,因此在某些情况下,如果需要在React事件处理程序之外强制执行批处理,则可以放心地使用它直到React 17。综上所述,这是一个令人困惑的话题,因为默认情况下,React仅在事件处理程序中进行批处理。这将在将来的版本中更改,并且行为将变得更加简单。但是解决方案不是少批处理,而是默认情况下多批处理。那就是我们要做的。

富国沪深

这实际上是一个非常有趣的问题,但答案应该不会太复杂。在媒体上有一篇很棒的文章有答案。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
打开App,查看更多内容
随时随地看视频慕课网APP