If the store gets informed by the action, it should decide if it needs to fetch some data. What you basically should be doing is, stating via actions what data you need. They are supposed to be like a newspaper that informs the application of a change in the outside world, and then the application responds to that news.
#Flux hacked client commands how to
I answered a related question here: How to handle nested api calls in fluxĪctions are not supposed to be things that cause a change. Hope that example helps a bit, as I found this a little tricky to implement, but certainly helped in keeping my stores 100% synchronous. You could imagine having different actions though which would respond to user interactions like addProduct(id) removeProduct(id) etc. So calling this.getFlux().() from any component listening to this store would load the products. In order to prevent multiple simultaneous requests to the same endpoint (for example, double-reading), I'll move the actual request processing into a separate module that uses promises to prevent the multiple requests for example: class MyResourceDAO )
#Flux hacked client commands code
The goal is to keep the store state modification code in fully synchronous action handlers this makes them simple to reason about and simple to unit test. I'm a big proponent of putting async write operations in the action creators and async read operations in the store.
0 kommentar(er)
