Flux: Getting Past the Learning Curve

If you’re like me, you’ve probably run across the multitude of React and Flux conversations across the Internets and thought it would be a good skill to pursue. Perhaps, like me, you’ve also been able to follow along with the Thinking in React tutorial that helps you understand how to create a basic React app. Maybe you’ve even started a React app and finished some basic functionality.

Then you get about seven React components and three handlers manipulating the state, and you start to understand where Flux comes in. Your app, although small, starts to become unwieldy as you try to manage the increasing amounts of application state passing through the various React components. This must be where Flux comes in.

Where do you start? Perusing through the many Flux tutorials brings a quick realization that the next step in your application’s architecture is not so simple. This isn’t like learning another NPM package to add to your app. This is like learning MVC all over again. There are some frameworks like Reapp that could be used as a shortcut to complete your app, but it’s probably better to get a foundational understanding of what Flux is doing first. Consequently, I am writing this article to take myself step-by-step through the development of a Flux-based React application.

Starting with a Mock

After a few minutes of creative drawing on the mobile app, I ended up with the following Marvel App:

Rudimentary and interactive todo app in five minutes

Beautiful. Now I have the visualization for some actions and views needed to complete this app. Before I get to the code, I’m going to continue my attempts to be a responsible programmer by writing down a basic outline of the app to understand the React and Flux pieces I’ll need.

To formally document what’s happening in this mock, here’s the outline:

  • Click the “+” to add text for a new todo item
  • Click the “+” (or hit [enter]) beside the todo item to save it
  • Click the “+” to add text for a second todo item
  • Click the “+” (or hit [enter]) beside the second todo item to save it
  • Click the “x” beside the second todo item to remove it

Compose the Actions

  • NEW_ITEM add a new todo item to the list for editing
  • SAVE_ITEM save the new item
  • REMOVE_ITEM remove a todo item from the list


Since JavaScript doesn’t have solid support of constants yet, creating mirrored key-pairs in all caps like this is the currently accepted convention in Flux.


When creating a dispatcher, a common convention is to create two handlers: one reacting to view triggered actions and one reacting to server triggered actions. I probably won’t have any server actions in this todo app, but I’ll add that part anyway for reference:


Create the Store

  • Require the Dispatcher, Constants, and event emitter dependencies
  • Define the store as an empty array
  • Define “public” event listeners and getters that views will use to listen for changes and retrieve the store (read only)
  • Register the store with the dispatcher and handle each of the actions that will change the store’s data by using a switch statement and emitting a change event

Putting all of this together looks like the following:

Construct the View

What’s the best way to compose the view? Well, since I already have a mock, it’s straightforward for me to use the Thinking in React approach to break down the view into components.

I’m sometimes tempted to skip this step, but it’s highly recommended to make a basic sketch for reference. The more components that are added to a project, the more difficult it is to remember the hierarchy without a visual aid.

With these components sketched out, I can now translate those directly into React components. Since I use JSX, I like to begin with a static HTML page and copy over the components starting with the inner-most elements first. For a large project, I might separate each of the components into separate files; but for simplicity, I’ll keep it all in the same Index.jsx. First, here is my starting HTML page:

When breaking these components into JSX, I realized I should probably add an EditItem component as well. This component could be dynamically added to bottom of the TodoList if the “editing” property of the state is true. In addition, I found this good flux-todomvc example that gave me many of the input text properties. The “onChange” property suggested the idea to keep the value of the edited item in the EditItem component’s state for easy access when saving the text. Finally, I searched the Bootstrap documentation and found the code for a little panel styling. In the end, these are the resulting React components:

The completed app can be found on GitHub.


Next steps? Perhaps handling the use of an API with Flux…

To cross-reference this guide with the new ES6 syntax, check out Migrating to ES6 with Babel and ESLint.


React.js Tutorial Pt 3: Architecting React.js Apps with Flux

Thinking in React

Flux TodoMVC

If you found this post helpful, please let me know by selecting the heart below to recommend it.

Husband, Full-Stack Developer, Recovering Sysadmin, Entrepreneur, 12-Factor/DevOps Advocate, #CavDad. Using @reactjs, #redux, and @reactnative.

Husband, Full-Stack Developer, Recovering Sysadmin, Entrepreneur, 12-Factor/DevOps Advocate, #CavDad. Using @reactjs, #redux, and @reactnative.