A store is what holds the data of an application. Stores will register with the application’s dispatcher so that they can receive actions. The data in a store must only be mutated by responding to an action. There should not be any public setters on a store, only getters. Stores decide what actions they want to respond to. Every time a store’s data changes it must emit a “change” event. There should be many stores in each application.
Examples:
- Store receives an “add-todo” action.
- It decides it is relevant and adds the todo to the list of things that need to be done today.
- The store updates its data and then emits a “change” event.
In Flux, Stores manage application state for a particular domain within your application. From a high level, this basically means that per app section, stores manage the data, data retrieval methods and dispatcher callbacks.
The most important thing we did above is to extend our store with NodeJS’s EventEmitter. This allows our stores to listen/broadcast events. This allows our Views/Components to update based upon those events. Because our Controller View listens to our Stores, leveraging this to emit change events will let our Controller View know that our application state has changed and its time to retrieve the state to keep things fresh.
