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.
Our build process during this series will utilize both gulp and browserify. In this lesson we will take a moment to setup our environment and all of the tooling required to begin developing our Flux Application. We've kept the build process very simple so porting it to grunt should be a breeze, but this also serves as a simple primer for those who may not be familiar with gulp.
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.
Flux has four major components: Stores, Dispatchers, Views, and Actions. These components interact less like a typical MVC and more like an Event Bus. In this lesson we will start by creating our Dispatcher which queues up our Actions as Promises and executes them as they are received. We'll also create an AppDispatcher which, unlike the Dispatcher, is more specific to our application.
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.
Actions contain no functionality, but rather describe an event in our application. In this lesson we will describe our Actions as they relate to our application. These Actions will then be available for triggering in our Views and for execution in our Store.
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.
Stores are where the real work in our application is done. Dispatchers broadcast Actions to all Stores, and the Stores registered to listen for those Actions will perform any logic needed to update our Views. In this lesson we will establish our first Store and register the Actions we wish to respond to.
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.
In Flux our Components are referred to as Views, but they are the same familiar Components associated with any React development. In Flux, however, we have the benefit of the architecture to keep us from having to pass down through a long chain of children Components any functionality that may be embedded in our Stores. In this Lesson we will wire up all of our Components in record time utilizing the architecture we've already established.
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.