Submit cascading / dependent asynchronous requests in Flux / React

Question

I know that this question has been asked more than once in different ways, but I have not yet found the “right” answer (maybe it just isn't), so I'm looking for the “most thread”.

A simple example:

• two components - LoginForm and Information
• the user must provide his registration information, send the form and only after that he / she has the right to "request" information (this should be done automatically after entering the system).

• Project structure in these lines:

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

Options:

one.

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

2.

• LoginForm._onSubmit() calls API.login()
• If API.login() is successful, it calls LoginAction.loginSuccess() and:
  • or InfoAction.requestInfo() , which calls API.requestInfo()
  • or API.requestInfo() , which then calls InfoAction.infoSuccess()

3.

• LoginForm._onSubmit() calls LoginAction.login()
• InfoStore listens for the LOGIN_OK action and calls API.requestInfo()
• API.requestInfo() calls InfoAction.infoSuccess() and dispatches an INFO_OK event with a payload of specific information that will be stored in InfoStore

(4.)

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

My mark:

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

2. It violates the “flow diagram” a bit - the components speak directly to the API or ServiceProviders, and not to ActionCreators. I'm not sure if this is good or bad. It seems to be “one-way” (good) and avoiding circular need (good). I personally prefer this option (in particular 2.2.)

3. I personally avoid this approach because it will mean that the Store is talking to an API / ServiceProvider that breaks the “flow diagram”, but again, I don’t know if this is really bad (maybe I'm just not used to to doing Flux stuff) Even @fisherwebdev seems to be okay with that (e.g. https://stackoverflow.com/a/16677/ ... ), but is this really the best approach?

4. Bad, bad, bad!

Question

Which one is the "best" and / or is there any other "very thread" for this?

Answer 1

I recently watched an informational discussion in which, among other things, there were two Facebook developers who worked on large-scale projects using React / Flux. I was struck by the fact that they took completely different approaches to the same problem - and both seemed completely good.

So, here is how I would handle this.

• LoginForm.onSubmit calls LoginAction.login .
• LoginAction calls API.login , and after success Dispatcher launches actionType with something like Constants.LOGGED_IN with user_id data
• A UserStore , listening to Constants.LOGGED_IN calls an API.userInfo call, passing the user_id that was in the user_id . (Having a store to get information directly from the API was one of the things that one of the FB guys said they regularly, reserving actions for updates and things of this nature.)
• UserStore stores information in its current_user and emits CHANGE
• Affected Components UserStore Upgrade to UserStore

Now, if you want to get more complicated, you can add arguments to your emit method emit that the affected components can get (a) the nature of the changes and (b) the actual data.

Hope this is food for thought!