11

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

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

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

因为该响应是成功的，所以我想发送一个操作将用户发送到主页：

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

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

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

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

我觉得一个setImmediate会工作，但它似乎有点脏。我还认为排队操作的调度程序可能会有所帮助，但我可以从骨子里感觉到这可能会导致令人讨厌的问题。

最好的方法是什么？

4

2 回答 2

8

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

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

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

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

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

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

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

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

于 2014-12-19T15:54:10.437 回答
4

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

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

于 2014-11-15T17:26:33.500 回答