Making your own Flux application: The King of Boilerplate

  • 9
  • 0

edit: ワウ〜 この記事は思ったより人気ですね。いつもReactのことは人気だし、

update oct-19: After using Flux for quite a while, I've started to become less annoyed by the amount of boilerplate used because in the end, it's MUCH harder to reason about React applications that use multiple component states. I may write about Flux again in an updated article, but only really to stress how centralized application state is what makes Flux a winner.

update oct-29: New article is live! Come see it here in its glorious cruddy quality:


Personally, I think the "Flux" architecture is quite an annoying collection of boilerplate code that is a stark contrast with the "cleanliness" of code that you can write in the components. Nonetheless, this is the "new hotness" for React developers whether we like it or not, and introduces yet another MVC design pattern for us to deal with.

Of course, the good people at Facebook very much object to their architecture being called "another MVC design pattern", but I haven't seen any responses from people outside of their team and the React cult agreeing with such a sentiment. Here are the common associations between what is introduced in Flux and "normal" MVC designs:

Flux "Normal" MVC
View View
Dispatcher Dispatcher/Controller
registered callback Controller
Stores Model
store-emitted events Model-View coupling
"change" handlers Model-View coupling

If you think my diagram is wrong, great. Send a pull request right away. I can't say that I'm an expert on deciphering what "Flux" is supposed to be other than an MVC pattern.

Flux workflow

With that out of the way, let's just get back to the "flow" of Flux and what you get to work with/write boilerplate for.

-> Actions 
-> Dispatcher 
-> Store
    -> callbacks
    -> functions 
    -> emit event 
-> Component

There's just so much boilerplate here that I'm not going to copy-paste it in this article. Instead, I will provide links.


This is my component tree. It starts at the app and pulls down a Table which in turn pulls down TableRows for each Show and includes a TableRowNew for entering new Show entities.

You'll see that in TableRow, on clicking the "delete" button, I will handle the delete action by using AppActions to start our chain to delete the entity. Great.


The action is a surprisingly simple thing -- it's a utility class that you expose with defined methods for what you want to get done. Two things you should know here: you pass an action object with your calls into the Dispatcher and must specify a actionType attribute, which is to be used in a glorious switch statement for handling. And guess what we use for entries for our cases? CONSTANTS.


Dispatcher really doesn't do anything other than just annoy you. It's only there to route your action object to your Store.


This is where everything happens. It's hard to say much about this, even though it handles a lot of responsibilities. It holds data and operates on it through "private" functions and then has a glorious switch statement for handling incoming requests from the dispatcher. Supposedly, the "cleanliness" of this store is supposed to justify all the boilerplate you wrote to get this working. Time will tell if it really was.


I can't even pretend to not be biased, I like Ember a lot more, but the cleanliness of component code makes React a much more accessible option at the moment, not to mention that the whole "virtual DOM" thing is the new hotness. Also that handlebars is ugly. That doesn't help either.

Github repository:


External/better readings

Flux Overview
Flux Tutorial


  • Kobito constantly jittering the page when I'm typing is really annoying.

  • I admit that working with Spring framework had more incomprehensible boilerplate in the XML files, but I like to pretend that doesn't exist.

  • I just can't be happy about the switch statement usage for supposedly defined handlers and the need for CONSTANTS to make this work. This really puts a bad taste in my mouth.