我有一个场景,我觉得我需要调度一个操作来响应另一个操作,但我不知道解决它的最佳方法。
调度一个操作来响应 HTTP 响应,例如:
type: 'auth'
data: { username: 'tom' }
因为响应成功,我想调度一个操作将用户发送到主页:
type: 'navigate'
date: { where: 'home' }
这对我来说似乎是一个明智的流程:这件事发生了,所以现在我希望这件事发生。问题是,通量调度程序不允许这样做,因为我们仍处于调度周期中。我明白为什么在调度时调度是一个坏主意。
有些人已经通过多个调度程序解决了这个问题,而 Flux 作者似乎确信您只需要一个调度程序,并且您需要重新考虑您的存储。
我不知道如何重组我的商店以促进这一点而不混淆意图。我的 UserStore
了解 auth
操作,我的 RouteStore
了解 navigate
操作。任何关于如何改变商店以促进这一点的建议将不胜感激。
我觉得 setImmediate
可以工作,但看起来有点脏。我还认为排队操作的调度程序可能会有所帮助,但我从骨子里感觉到这可能会导致严重的问题。
解决这个问题的最佳方法是什么?
最佳答案
您应该回顾一下您是如何尝试创建此流程的。
你说你需要创建一个 Action 来响应另一个 Action ,对吗? 因此,我们将其命名为“ActionForwarderStore”。
我们最终得到这样的流程:
AuthAction --> Dispatcher --+--> UserStore
|
+--> ActionForwarderStore --+
|
+--------------------------------------------+
|
+-> Dispatcher -----> RouteStore
您发现您仍然有人理解 AuthAction
最终应该更改路线吗?这是ActionForwarderStore
。正如 Flux 建议每个 Store 都会监听每个 Action,因此对最终导致路由更改的 AuthAction
的了解可以直接进入 RouteStore
。像这样:
AuthAction --> Dispatcher --+--> UserStore
|
+--> RouteStore
请记住,Flux 是为了避免 MVC 的不可预测性而“创建”的。如果您将所有路线更改保存到 RouteStore
中,则只需查看此 Store 代码即可了解哪些 Action 会导致路线更改。如果您采用创建一个操作来响应另一个操作的方式,您将只知道 NavigateAction
更改了路线,并且您将需要查看其他商店来检查哪些商店正在触发此操作回应其他人。
这就是 Flux 所说的“单向流”。通过这种方式很容易发现问题,因为这是唯一允许的流。如果您单击一个按钮并更改了路线,您可以确定单击分派(dispatch)的操作正在导致路线更改,不存在级联操作。
关于reactjs - 处理操作时分派(dispatch)进一步的操作,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/26934953/