The flux dispatcher is not a traditional event emitter that we, javascript developers, know and love. The flux dispatcher is meant to broadcast unidirectional messages. Messages, that are emitted by one or more publishers to a single subscriber. This gives rise to some interesting patterns and is a nice solution that decouples UI components from the application stores.
For the sake of understanding these concepts, i'm going to call the single subscriber a 'registered callback'; and let's call the messages emitted by the publishers, 'payloads'.
// ex. registered callback
const token = dispatcher.register(payload => {
// handle payload data
})
At a glance, the registered callback may seem completely useless, since using a traditional pub/sub subscriber (via .on
method) works perfectly, but using a basic event emitter becomes problematic when modeling application into stores. The data coming in from the server is relational (the majority of the time). So for each update in a relational data store would require updates to cascade from parent dependencies. The flux dispatcher solves this issue with promises.
The flux dispatcher has method called .waitFor
. This method leverages promises to wait for each parent dispatcher to resolve before invoking the next child registered callback.
//[dispatch: Update Store 3] -> [Update Store 1] -> [Wait for: Store 1] -> [Wait for: Store 2] -> [Update Store 3]
The .waitFor(id)
method knows the order in which to invoke each registered callback via a dispatcher token.
fin.