React this.setState 会正确排队吗？

Question

当我检查React setState

将 setState() 视为更新组件的请求而不是立即命令。 为了更好的感知性能，React 可能会延迟它，然后一次更新多个组件。 React 不保证立即应用状态更改。

而这个状态更新可能是异步的

React 可以将多个 setState() 调用批处理为单个更新以提高性能。 因为 this.props 和 this.state 可能会异步更新，所以你不应该依赖它们的值来计算下一个状态。

底层机制是什么？ 据我了解，这不是批量更新而是按照先进先出规则排队吗？

我试图确保setState 的这个FIFO规则如下：

this.setState({loading: true});
...// no matter what happened here as long as it's not stopped by errors;
this.setState({loading: false}); // the loading will always be set to **false**;

所以我不需要像以下丑陋的方式来处理这个：

this.setState({loading: true}, () => {
    ...
    this.setState({loading: false});
});

最后，当我检查这个Functional setState 是 React 的未来时，我认为它确实遵循FIFO规则。

非常清楚，将对象传递给 setState() 不是这里的问题。 真正的问题是当您想从前一个 state 计算下一个 state时将 object 传递给 setState() 。

哈哈，一劳永逸

报价从丹·阿布拉莫夫

使用一个函数多次调用 setState 是安全的。 更新将被排队，稍后按照它们被调用的顺序执行。

如果我错了，请纠正我。 如果可用，请分享更多详细信息。

谢谢！

Answer 1

您似乎没有正确地分派动作，诺言也需要用分派而不是像

  dispatch(askForData()).then(() => {
    ...
    this.setState({ loading: false });
  };

Answer 2

是的，你可以setState连续多次，最后通话将决定你的状态值（如果设置相同的密钥，当然）。

确切地说， setState优先考虑，更新的顺序可能与setState调用不完全相同。 可以跳过某些呼叫，然后在CPU有更多时间提供之后重播。 （很像git rebase）。

您可以从react源代码中了解有关此文件的更多信息。

因为React可以批量更新（如果覆盖了旧值，则忽略旧值），因此存在一种情况，您可能需要在另一个setState回调中调用setState ，这是您需要状态临时具有特定值的情况。

您可能会想象一个className取决于状态，需要添加一个className，然后将其从DOM中快速删除以执行动画。

Answer 3

看看丹·阿布拉莫夫的这篇文章来回答这个问题。

根据我对上述帖子的理解，您可以假设整个 React 项目有一个队列 (FIFO) ，所有更新都将排入队列并稍后执行。 现在您可以看到setState顺序在单个组件中甚至在不同组件之间都受到尊重。

您也可以阅读这篇文章，但作者在这里说

事实证明，每个钩子都有一个更新队列。

而Dan Abramov的回答说即使在不同的组件之间也尊重setState顺序，我相信这只能通过像结构一样的单个队列而不是多个队列，即每个useState挂钩的队列。

我希望我可以在这里标记@Dan Abramov以请求他的验证。