在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的方式，因为我们应该避免chaning行为。只是一劳永逸。

2。 稍微打破“Flux图” - 组件与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，成功后，调度程序会启动类似Constants.LOGGED_IN的actionType，其中包含user_id
的数据
3. UserStore，听Constants.LOGGED_IN拨打API.userInfo，传递发送中的user_id。 （让商店直接从API获取信息是其中一个FB人员说他们经常做的事情之一，保留更新和这种性质的行为。）
4. UserStore将信息保存到current_user并发出CHANGE
5. 受影响的组件请求更新UserStore

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

希望这是值得深思的！