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

Question

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

简单示例：

• 两个组件 - 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() 并且：
  1. InfoAction.requestInfo() 调用 API.requestInfo()
  2. 或 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://stackoverflow.com/a/26637579/5053194），但这真的是最好的方法吗？

4。 糟糕，糟糕，糟糕！

问题

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

Answer 1

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

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

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

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

希望这是值得深思的！