3 ms·

Three ReactJS and Flux commandments

4 points by kriswallsmith 12y ago

Kjeldahl 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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 12y ago
        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. :-)

4 points by kriswallsmith 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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. :-)