

Three ReactJS and Flux commandments - kriswallsmith
http://kriswallsmith.net/post/113538449364/three-reactjs-flux-commandments

======
Kjeldahl
Update: I was probably wrong in disagreeing; actions from actions works if
they are on different stores, but to stay away from trouble you're probably
better off creating "followup async actions" from stores rather than other
actions.

Original comment:

I'm not sure I agree with the first point. Let's say your store's HTTP
requests fails and you want to inform the user (through the view component).
You want to listen to yet another event from the same store to catch this? An
alternative is to do exactly what you say you shouldn't do in step 1;
basically have a "loadDataAction" that you fire off when your component gets
mounted, using some unique id or something. Prior to this action, the store
will return whatever it has (synchronously, similar to what you describe). The
action then handles the HTTP request. If it succeeds, it updates the store,
and the listener will get the updated data (yes, I agree, the component should
always have a listener to the store). If it fails, the same "loadDataAction"
will fire off a "showMessageAction" which also alters some store that your
component listens to that will display the error message. Typically this would
be caught by some higher-up global "show message" component. Like most people,
I'm pretty new to a lot of this as well, but I have found that trying to keep
most async stuff in the actions works a lot better than async everywhere.
YMMV.

~~~
kriswallsmith
If you want to show an error when an AJAX request fails, that failure
constitutes a change in application state, which should be reflected in a
server action. This action would end up in an ErrorStore, which a
DisplayErrors component would be listening to somewhere. If you show an alert
dialog (for example), the user closing that dialog would also constitute a
change in application state, as the error has been dismissed, which would be
reflected in a view action, which would eventually get to the ErrorStore and
remove that error.

~~~
Kjeldahl
This we agree on. But if you're doing your async stuff in your store, is this
where you want to create your "setErrorAction", essentially creating actions
inside your stores? The times I've done this it has ended painfully, and that
pain went away if I kept these kind of state updates in actions.

~~~
kriswallsmith
Yes, the error action creator would be called from inside the store, which
would in turn call handleServerAction. You may have been attempting to
dispatch an action inside of an action, which isn't allowed. I hit that wall a
few times.

~~~
Kjeldahl
You're right, I'm wrong. An cycle needs to complete before another action can
be dispatched (against the same store I believe). I think I need some rest.
:-)

