处理操作时调度进一步的操作

时间:2014-11-14 16:49:24

标签: reactjs reactjs-flux

我有一个场景,我觉得我需要发布一个动作来回应另一个动作,而且我不知道解决它的最佳方法。

调度操作以响应HTTP响应,例如:

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

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

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

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

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

我不知道如何在不模糊意图的情况下对我的商店进行重组以促进这一点。我的UserStore了解auth次操作,RouteStore了解navigate次操作。关于如何改变商店以促进这一点的任何建议将不胜感激。

我觉得setImmediate会起作用,但看起来有点脏。我还认为排队行动的调度员可能有所帮助,但我可以感觉到这可能会导致令人讨厌的问题。

最好的方法是什么?

2 个答案:

答案 0 :(得分:8)

您应该回顾一下如何创建此流程。

你说你需要创建一个动作来响应另一个动作,对吧? 所以,让我们将其命名为" ActionForwarderStore"。

我们最终得到了这样的流程:

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

您是否仍然有人了解AuthAction最终应该更改路线?这是ActionForwarderStore。由于Flux建议每个商店都会收听每个操作,因此在路径更改中结束的AuthAction知识可以直接进入RouteStore。像这样:

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

请记住,Flux是"创造的"为了避免MVC的不可预测性。如果您将所有路线更改保留为RouteStore,则只需查看此商店代码即可了解哪些操作会导致路线更改。如果您为了响应另一个动作而阻碍创建动作,您将只知道NavigateAction更改路线,并且您需要查看其他商店以检查哪些商店正在触发此动作以响应其他

这就是Flux命名为"单向流"。以这种方式捕获问题很容易,因为这是唯一允许的流程。如果单击某个按钮并更改了路径,则可以确定单击调度的操作导致路由更改,没有级联操作。

答案 1 :(得分:4)

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

因此,在这种情况下,您只会在UserStore和RouteStore中响应'auth'。