在 Flux/React 中调度级联/依赖异步请求

Posted 2023-02-22

【中文标题】在 Flux/React 中调度级联/依赖异步请求

【英文标题】：Dispatching cascading/dependent async requests in Flux/React

【发布时间】：2015-09-13 14:57:41

【问题描述】：

我知道这个问题已经被多次以不同的方式问过，但我还没有找到“正确”的答案（也许根本就没有），所以我正在寻找“最通量”的答案.

简单示例：

两个组件 - LoginForm 和 Information 用户必须提供他/她的登录信息，提交表单，然后他/她才有权“询问”信息（这应该在登录后自动完成）

项目结构如下：

+ actions
|-- LoginAction
|-- InfoAction
+ api
|-- API
+ components
|-- LoginForm
|-- Information
+ stores
|-- LoginStore
|-- InfoStore

选项：

1.

LoginForm._onSubmit() 致电LoginAction.login() LoginAction.login() 使用回调/承诺调用 API.login()，然后在成功登录的情况下调用 InfoAction.requestInfo()

2.

LoginForm._onSubmit() 致电API.login() 如果API.login() 成功，它会调用LoginAction.loginSuccess() 并且：

InfoAction.requestInfo() 调用 API.requestInfo() 或 API.requestInfo() 然后调用 InfoAction.infoSuccess()

3.

LoginForm._onSubmit() 致电LoginAction.login() InfoStore 监听 LOGIN_OK 动作并调用 API.requestInfo() API.requestInfo() 调用 InfoAction.infoSuccess() 并调度 INFO_OK 事件，其中包含将存储在 InfoStore 中的特定信息的有效负载

(4.)

从componentWillMount 或componentDidMount 调用API/ServiceProvider 或ActionCreators 似乎天生就不好。不是一个（好的）选择，但为了完整起见，我把它放在这里。

我的评价：

1。 擅长基于回调/承诺的 JS 的“旧风格”，但似乎不是 Flux 方式，因为我们应该避免更改操作。只需一劳永逸。

2。 稍微打破“通量图” - 组件与 API 或 ServiceProviders 对话，而不是直接与 ActionCreators 对话。我不确定这是好是坏。它似乎是“单向”（好）并避免了循环要求（好）。我个人更喜欢这个选项（特别是 2.2.一个）

3。 我个人避免使用这种方法，因为这意味着 Store 与 API/ServiceProvider 交谈会破坏“Flux 图”，但同样，我不知道这是否真的很糟糕（也许只是我不习惯 Flux 的做法事物）。甚至@fisherwebdev 似乎也可以接受（例如https://***.com/a/26637579/5053194），但这真的是最好的方法吗？

4。 糟糕，糟糕，糟糕！

问题

哪一个是“最好的”和/或是否有任何其他“最通量”的选项可以做到这一点？

【参考方案1】：

我最近观看了一个内容丰富的小组讨论，其中有两位 Facebook 开发人员正在从事使用 React/Flux 的大型项目。令我印象深刻的是，他们对同一个问题采取了完全不同的方法——而且看起来都非常好。

也就是说，这就是我的处理方式。

LoginForm.onSubmit 致电LoginAction.login。 LoginAction 调用 API.login，成功后，Dispatcher 使用 user_id 的数据启动类似 Constants.LOGGED_IN 的 actionType 监听Constants.LOGGED_IN 的UserStore 调用API.userInfo，传递调度中的user_id。 （让商店直接从 API 获取信息是 FB 人员说他们经常做的事情之一，为更新和类似性质的事情保留操作。） UserStore 将信息保存到其 current_user 并发出 CHANGE 受影响的组件请求更新到UserStore

现在，如果您想变得更棘手，您可以让商店为其emit 方法添加参数，以便受影响的组件可以获取 (a) 更改的性质和 (b) 实际数据。

希望这是值得深思的！

【讨论】：

你可能就在这里，但我个人认为这打破了“通量流程图” - Broken flux diagram 是的，FB 开发人员似乎对此没意见（他们可能是这方面的权威问题），但我只想在一个地方有异步代码。第二件事是它可能导致“循环要求” - 1. API 要求 ActionCreator (AC) 调用 AC.infoReceived() 2. 当组件这样说时，AC 要求 API 调用 API.getNextInfo()。

哦，我不一定要在这里谈论“用户信息” - 只是一些“一般信息”（第二天的天气报告，一天的图片）只有在登录后才能访问（behing paywall.. .)。但这只是为了澄清我的思路，在这种情况下应该没有区别。

@TooManyQuestions，你最后得到了什么？