In the preceding section, we caught a glimpse of some of the potential challenges with the Facebook reference implementation of a Flux dispatcher. In this section, we'll elaborate on some some of this reasoning, in an attempt to provide motivation to implement our own custom dispatcher.
In this section, we'll reiterate the fact that the Flux NPM package mainly exists as an educational tool. Depending on a package like this is fine, especially since it does the job, but we'll go over some of the risks that something like this carries in a production context. Then, we'll talk about the fact that dispatcher components are singleton instances and they probably don't need to be.
We'll then think about the store registration process and the fact that it's a more manual process than it needs to be. Finally, we'll touch on the store dependency management problem again with a discussion on waitFor() and possible declarative alternatives.