0

Short version of the question:

Can I fire UI actions from the store?

Long version of the question:

I'm writing food delivery app with reflux. It's seems like I'm not quite understand how actions should go in my applications.

I have BasketStore, StatusOverlay (component) and actions:

// BasketStore actions
basketSync
basketSync.Completed
basketSync.Invalid
basketSync.Failed

// StatusOverlay actions
statusOverlayOpen
statusOverlayClose

The application works the following way:

I press button and send basketSync action. Once it happened the overlay is starting to be shown and BasketStore sends request for the data to the server.

Then accordingly to server response I fire basketSync.completed, basketSync.failed, basketSync.invalid. When it invalid or completed I close overlay, otherwise I show another overlay.

The question is how should I manage actions? Should I listen to basketSync inside of StatusOverlay to open it and close it on basketSync.completed, basketSync.invalid or it will be better to listen to just statusOverlayOpen, statusOverlayClose and fire these actions somewhere inside of BasketStore.

Tikhon Belousko
  • 767
  • 1
  • 9
  • 26

2 Answers2

3

Short answer: In the standard Flux architecture, Flux stores should only emit a simple CHANGE event, so, no, you can't fire UI actions from the store.

Hal Helms
  • 684
  • 3
  • 8
2

I've seen stores triggering actions in many Flux applications. Some people like to put their async work inside the action creators and trigger "completed" and "failed" "sub-actions" inside the callbacks of the async work, others put the async work within the store itself and in that case trigger the sub-actions from there. They key point, as I've seen it pointed out, is that in the callbacks you should trigger a new action, rather than update state directly, so that data mutations only ever happens as an effect of actions, not async callbacks.

But with that said, components should not typically listen to actions at all. They should only listen to updates to the store and reflect that update any way necessary. So with the points mentioned above, stores could listen to the "completed" or "failed" actions, and appropriately update their state to reflect the "completed" or "failed" actions. The components then render any "error" indications based on the store's state, not on actions directly.

Hannes Johansson
  • 1,794
  • 2
  • 15
  • 28