javascript - 为什么将 redux 调用包装到 promise 中允许访问结果 "immediately"

Question

所以我们有一个 redux(带有 thunk 中间件)/react 环境。我们有以下代码:

onMyClick = () => {
    this.props.mySynchronousActionWhichWillCreateNewReducerState();
    this.setState(...my state change which wants to see the new reducer state...);
}

由于代码是同步的，因此不会以这种形式工作。这意味着 React 生命周期永远不会用新的 Prop 更新自己。然而，如果我们这样改变它:

onMyClick = () => {
    Promise.resolve(this.props.myActionWichWillCreateNewReducerState())
           .then(
              () => this.setState(...my state change which want to see the new reducer state...)
           );
}

它现在按“预期”工作(调度触发新的 reducer 状态，组件更新，然后 setState 运行)。首先，我认为这个解决方案容易出错并且有效，因为我们通过异步性“赢得”了一点时间，允许更新在 setState 之前启动。但它永远不会失败，(你可以让代码在 Action 中变慢，或者在 reducer 中，在中间件中，在组件更新中，在你想要的任何地方，它仍然有效)。

为什么？

---

一些解释可能是合理的，为什么我很难理解这一点。更多的是“为什么它会这样工作”而不是“它是如何工作的”

所以首先让我们看看这两段代码，就像普通的 javascript 一样。在这种情况下 - 至少对我来说 - 第一个应该有效，第二个不应该。或者至少第二个应该是模糊的。

首先: 我进行了同步调用(调度->操作创建->存储更改)，然后我进行了另一个调用，但第二个无法预期第一个所做的更改。我必须知道 redux 和 react 如何非常密切地运作才能知道如何以及为什么。顺便说一句，你甚至可以改变 redux 存储(大不，不)，而不是从 reducer 返回一个新对象来保留引用，但它仍然不起作用。令人难以置信的是，你同步地改变一个对象，然后无法访问之后的变化......

第二个: 在这种情况下(就像 Jaromanda X 评论的那样)我“似乎”告诉代码“嘿，并行运行这两段代码”。现在它起作用了，而且一直起作用。哇。将我对 React 生命周期的理解(看起来很肤浅)添加到组合中会使它更加自相矛盾。因为这意味着更多的逻辑 - react 生命周期更新 - 将不得不“超过”setState 调用才能工作。

如果这不是背后有所有支持和智能的 redux/react 环境，我会说这种代码行为闻起来像 hell ，闻起来像黑魔法和 go-to :)。

Answer 1

当您将一段代码包装在一个 promise 中时，您实际上是在将其执行延迟至少 1 个 tick。对于您的代码，这段时间足以让 reducer dispatch 完成更新。因此，当 then 中的代码被执行时，它获得了更新的值，因为 this.state 是一个对象，即使在闭包中它也总是指向一个内存引用，这将是已更新。

也就是说，redux 中的 reducer update 或 React 中的 setState 都不会返回 promise。您的代码相当于:

Promise.resolve(console.log("dummy")).then(() => console.log("second"));
console.log("first")

first 将始终在 second 之前打印，因为 promisified 片段在事件队列的下一个 tick 中执行。

你的代码目前不容易出错，因为 React 决定 1 个 tick 足以更新状态。但不要依赖于它，因为对于其他一些代码或 React 的更高版本，更新所需的时间可能会改变。