我有一个场景，我觉得我需要发送一个动作来响应另一个动作，我不知道解决它的最佳方法。
调度操作以响应HTTP响应，例如：
type: 'auth'
data: { username: 'tom' }
由于该响应成功，我想发送一个动作将用户发送到主页：
type: 'navigate'
date: { where: 'home' }
这对我来说似乎是一个明智的流程：这件事发生了，所以现在我希望这件事发生。麻烦的是，Flux Dispatcher不允许这样做，因为我们仍在调度周期中。我知道为什么在调度时调度是一个坏主意。
有些人已经通过多个调度员解决了这个问题，而Flux的作者似乎确信你只需要一个，而你需要重新考虑你的商店。
我不知道如何在不模糊意图的情况下重构我的商店以促进这一点。我的 UserStore 知道 auth 行动，我的 RouteStore 知道 navigate 动作。关于如何改变商店以促进这一点的任何建议将不胜感激。
我觉得自己像个 setImmediate 会工作，但似乎有点脏。我还认为排队行动的调度员可能会有所帮助，但我可以感觉到这可能会导致令人讨厌的问题。
最好的方法是什么？
通常，此问题的解决方案是备份并查看原始操作，并等待您尝试在第二个操作中发送的值（如果需要派生值）。
因此，在这种情况下，您只会在UserStore和RouteStore中响应'auth'。
通常，此问题的解决方案是备份并查看原始操作，并等待您尝试在第二个操作中发送的值（如果需要派生值）。
因此，在这种情况下，您只会在UserStore和RouteStore中响应'auth'。
您应该回顾一下如何创建此流程。
你说你需要创建一个动作来响应另一个动作，对吧？
所以，让我们将其命名为“ActionForwarderStore”。
我们最终得到这样的流程：
AuthAction --> Dispatcher --+--> UserStore
|
+--> ActionForwarderStore --+
|
+--------------------------------------------+
|
+-> Dispatcher -----> RouteStore
你看，你仍然有一个人了解这一点 AuthAction 应该最终改变路线？这是 ActionForwarderStore。由于Flux建议每个商店都听取每一个Action，这个知识就是 AuthAction 最终路线变化可以直接进入 RouteStore。喜欢这个：
AuthAction --> Dispatcher --+--> UserStore
|
+--> RouteStore
请记住，Flux是“创建”的，以避免MVC的不可预测性。如果您保留所有路线更改 RouteStore，您只需要查看此商店代码，以了解哪些操作将导致路由更改。如果您为了响应另一个动作而阻碍创建动作，那么您将只知道这一点 NavigateAction 更改路线，您需要查看其他商店以检查哪些商店正在触发此操作以响应其他商店。
这就是Flux所说的“单向流”。以这种方式捕获问题很容易，因为这是唯一允许的流程。如果单击某个按钮并更改了路径，则可以确定单击调度的操作导致路由更改，没有级联操作。