When Facebook presented Flux, the architecture they were using internally to develop applications (specially coupled with React), they didn’t provide a reference implementation — just the concept of how to architect applications around the flux ideas and the benefits from this approach. The Facebook’s Flux team did provide a small todo example with a self proclaimed “naive” implementation of a dispatcher, just for the sake of illustrating the concept, but it took some time for them to open source their reference dispatcher and more complete examples and documentation.

This is not a bad thing, as it helped convey the message that Flux is an idea, an architecture, and not a library, but because Flux immediately resonated with the community, lots of guides and tutorials as well as a profusion of libraries emerged in the meantime. And by the time Facebook open-sourced its reference dispatcher implementation, some misunderstandings and cargo-culting has spread. Things like:

Helper methods:

Helper methods can be really useful if you are using them consciously on your app. Blindly copying those methods from the examples only add to boilerplate. Overall modules structures:

Facebook made the deliberate decision to keep Flux library minimum (for practical purposes, it only contains a dispatcher). This means you get to build Stores, Constants and Action creators as plain javascript objects. Beginners tend to copy these files structures from the Flux examples, and there’s nothing wrong with this, but it’s important to know you can shape them to better fit your app and taste. Some people, for example, get specially mad about the big switch statements inside a store dispatcher callback — but since it’s just plain javascript it’s easy to achieve similar results with different approaches.

In this small article i’d like to show some specific cases where cargo-cult usually appears and which are the alternatives: