Gentle Introduction to the React Flux Architecture

React is the "V" in your MVC, but with the Flux Application Architecture you can add the "M & C" to easily wire up components into a working application.

To get you started, we've published a series. We'll start with 5 (free) lessons as an introduction, and then move into building a real-world React Flux example application.


There are a multitude of GruntJS boilerplates I can fire up to kick off a new Angular project, but when working with the 'newfangled', I prefer to keep it all 'newfangled', so choosing GulpJS and Browserify as a build process makes perfect sense.

This is how we learn, dive in head first and figure out the quirks as we go. Turns out, though, that GulpJS and Browserify are more than capable counterparts to existing build processes... dare I say, even superior to them? With GulpJS we get clear JavaScript, rather than configuration, and with Browserify we get to tap into all those lovely npm modules we wish we had in the browser.


As an Angular developer I have run into the dilemma that is either 'service as state' or 'event driven madness' and while Flux appears to be as event driven as some of my nightmares, the idea of a Dispatcher is clean, clear, and even surfacing with many Angular devs I know in the form of an Event Bus.

The Flux Dispatcher, a.k.a. the Flux Traffic Cop, is a reasonable step towards solving the pains of event-driven design. To do something like this in Angular we'd really need a destination parameter as our actions are queued up to avoid a bunch of directives blindly bleating out actions into the $rootScope unaware of all the $watches about to be triggered, but thanks to the Virtual DOM this is less of a concern in React.


In any reasonably sized application all devs eventually find a need to identify all of the events in the app. Flux very politely formalizes this process by having us take the time to not only identify the events as Actions, but also to organize them in a more meaningful manner than just a list of strings to broadcast.


If Services were mandatory in Angular they'd be the Flux Store. Just like in Angular where we could place a lot of logic into a directive or controller we could do the same in a React Component, but having this very clear line of sight from Action to Dispatcher to Store to View makes doing so in Flux almost immediately recognizable as an anti-pattern.


React Components are often compared to Angular Directives and I definitely see the similarity, but in my opinion React Components are what a good Directive should be. Dumb.