在处理动作时调度进一步的动作

Question

我有一个场景，我觉得我需要调度一个动作来响应另一个动作，但我不知道最好的解决方法。

为了响应 HTTP 响应而调度操作，例如：

type: 'auth'
data: { username: 'tom' }

由于响应成功，我想发送一个动作将用户发送到主页：

type: 'navigate'
date: { where: 'home' }

这对我来说似乎是一个明智的流程：这件事发生了，所以现在我希望这件事发生。麻烦的是，Flux Dispatcher 不允许这样做，因为我们仍处于调度周期中。我明白为什么在分派时分派是个坏主意。

有些人已经通过多个调度程序解决了这个问题，而 Flux 作者似乎确信您只需要一个并且您需要重新考虑您的商店。

我不知道如何在不混淆意图的情况下重组我的商店以促进这一点。我的UserStore 知道auth 动作，我的RouteStore 知道navigate 动作。任何关于如何改变商店以促进这一点的建议将不胜感激。

我觉得setImmediate 会起作用，但它似乎有点脏。我还认为排队操作的调度程序可能会有所帮助，但我能从骨子里感觉到这可能会导致严重的问题。

最好的办法是什么？

Answer 1

您应该回顾一下您是如何尝试创建此流程的。

你说你需要创建一个动作来响应另一个动作，对吧？ 因此，我们将其命名为“ActionForwarderStore”。

我们最终得到这样的流程：

AuthAction --> Dispatcher --+--> UserStore
                            |
                            +--> ActionForwarderStore --+
                                                        |
           +--------------------------------------------+
           |
           +-> Dispatcher -----> RouteStore

您看到您仍然有人了解AuthAction 应该最终改变路线吗？这是ActionForwarderStore。正如 Flux 建议的那样，每个 Store 都监听每个 Action，这种关于 AuthAction 最终导致路由更改的知识可以直接进入 RouteStore。像这样：

AuthAction --> Dispatcher --+--> UserStore
                            |
                            +--> RouteStore

记住 Flux 是为了避免 MVC 的不可预测性而“创建”的。如果您将所有路由更改保存到RouteStore，您只需查看此 Store 代码即可了解哪些操作会导致路由更改。如果你去创建一个action来响应另一个action，你只会知道NavigateAction改变了路由，你需要查看其他Store来检查哪些是触发这个action来响应其他的。

这就是 Flux 所称的“单向流”。通过这种方式很容易发现问题，因为这是唯一允许的流程。如果您单击一个按钮并更改了路由，您可以确定单击分派的操作导致路由更改，没有级联操作。

Answer 2

通常，此问题的解决方案是备份并查看原始操作，如果需要派生值，则等待您尝试在第二个操作中发送的值。

因此，在这种情况下，您将只响应 UserStore 和 RouteStore 中的“auth”。