调度级联/异步依赖于请求流量/阵营

问题描述

我知道这个问题已经被问多次在不同的口味，但我没有找到正确的答案了（或许只是没有之一），所以我在寻找最流量一

简单的例子：

• 两部分组成 - LoginForm的和信息


• 的用户必须提供他/她的登录信息，提交表单，之后才是他/她有权要问的信息（这应该做登录后自动）



• 沿着这些线路工程结构：

    +行动
  |  - 的LoginAction
  |  -  InfoAction
  + API
  |  -  API
  +组件
  |  -  LoginForm的
  |  - 信息
  +专卖店
  |  -  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）。

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

我的评价：

1。
好在回调/基于承诺JS的旧式，但似乎并没有成为流量的方式，因为我们应该避免chaning行动。刚刚发射后不管。

2。
打破了流量图略微 - 组件API或ServiceProviders而不是直接ActionCreators说话。我不知道这是否是好还是坏。这似乎是单向（好），避免通知要求（好）。我个人preFER此选项（特别是2.2的）

3。
我本人来说避免这种做法，因为这意味着商店谈话的API /的ServiceProvider它打破了流量图，但同样，我不知道这是非常糟糕的（也许这只是我没有被用来干什么的流量方式事情）。即使@fisherwebdev似乎是确定与此（如）但是否真的最好的办法？

4。
坏，坏，坏了！

问题

哪一个是最好的和/或有任何其他最流量选项来做到这一点？

解决方案

我最近看了那有，除其他外，使用了两个Facebook开发的大型项目工作作出反应/助焊剂一个信息小组讨论。让我印象深刻的是，他们采取了完全不同的方法解决同一问题 - 两者似乎完全好

这是说，这里就是我会处理它。

1. LoginForm.onSubmit 要求 LoginAction.login 。


2. 的LoginAction 要求 API.login ，一经成功，分派推出的一种东西像操作类型 Constants.LOGGED_IN 与 USER_ID
   
3. A UserStore ，收听 Constants.LOGGED_IN 使得以 API.userInfo通话，通过了 USER_ID 这是在调度。 （有一个商店直接从API获取信息是事物的FB家伙一一说，他们经常做的，保留了这种性质的更新和东西的动作。）


4. UserStore 保存信息到其 CURRENT_USER 并发出更改


5. 受影响的组件请求更新到 UserStore

现在，如果你想获得棘手，你可以有存储添加参数到它的 EMIT 法，使受影响的组件可以拿起（一）性质是什么改变和（b）的实际数据。

我们希望，这是回味无穷！

I know this question has been asked more times in different flavours, but I didn’t find the "right" answer yet (maybe there just isn't one), so I’m looking for the "most Flux" one.

Simple example:

• two components - LoginForm and Information
• user has to provide his/hers login information, submit the form and only after that he/she has right to "ask" for the information (this should be done automatically after login)

• Project structure along these lines:

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

Options:

1.

• LoginForm._onSubmit() calls LoginAction.login()
• LoginAction.login() calls API.login() with callbacks/promises and then in case of successful login it calls InfoAction.requestInfo()

2.

• LoginForm._onSubmit() calls API.login()
• if API.login() is succesful it calls LoginAction.loginSuccess() and:
  1. either InfoAction.requestInfo() which calls API.requestInfo()
  2. or API.requestInfo() which then calls InfoAction.infoSuccess()

3.

• LoginForm._onSubmit() calls LoginAction.login()
• InfoStore listens to LOGIN_OK action and it calls the API.requestInfo()
• API.requestInfo() calls InfoAction.infoSuccess() and that dispatches INFO_OK event with payload of the specific info that is going to be stored in InfoStore

(4.)

calling API/ServiceProvider or ActionCreators from componentWillMount or componentDidMount seems inherently bad. Not really a (good) option, but I’m putting it here for the sake of completeness.

My evaluation:

1.Good in the "old style" of callback/promise based JS, but doesn’t seem to be the Flux way, because we should avoid chaning actions. Just fire-and-forget.

2.Breaks the "Flux diagram" slightly - components speak to API or ServiceProviders and not to ActionCreators directly. I'm not sure about whether this is good or bad. It seems to be "one-way" (good) and avoids circular requires (good). I personally prefer this option (specifically the 2.2. one)

3.I personaly avoid this approach because it would mean Store talking to the API/ServiceProvider which breaks the "Flux diagram", but again, I don’t know if it’s really bad (maybe it’s just me not being used to the Flux way of doing things). Even @fisherwebdev seems to be ok with this (e.g. http://stackoverflow.com/a/26637579/5053194), but is it really the best approach?

4.Bad, bad, bad!

Question

Which one is "the best" and/or is there any other "most Flux" option to do this?

解决方案

I recently watched an informative panel discussion that had, among others, two Facebook developers working on large-scale projects that used React/Flux. What struck me was that they took completely different approaches to the same problem -- and both seem perfectly good.

That said, here's how I'd handle it.

1. LoginForm.onSubmit calls LoginAction.login.
2. LoginAction calls API.login and, upon success, the Dispatcher launches an actionType of something like Constants.LOGGED_IN with data of the user_id
3. A UserStore, listening for Constants.LOGGED_IN makes a call to API.userInfo, passing the user_id that was in the dispatch. (Having a store get information directly from the API was one of the things one of the FB guys said they do routinely, reserving actions for updates and things of that nature.)
4. UserStore saves info into its current_user and emits a CHANGE
5. Affected components request an update to UserStore

Now, if you want to get trickier, you can have the store add arguments to its emitmethod, so that the affected components could pick up (a)the nature of what changed and (b)the actual data.

Hopefully, that's food for thought!

这篇关于调度级联/异步依赖于请求流量/阵营的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！