Welcome to Part 9 of this new series reviewing Cory House’s Pluralsight course Building Applications with React and Flux.

Cory is a Microsoft MVP in C#, founder of OutlierDeveloper.com, avid tech reader, and speaker.

He believes in clean code, pragmatic development, and responsive native UIs.
Building Applications with React and Flux is the prequel to Cory’s course Building Applications with React and Redux in ES6.

If you are new to React JS or React-Router, or prefer to do your development in regular JavaScript without using Babel and other tools that you don’t necessarily need, then this course is for you. Alternatively, check out the review of his other React course above.

Also in this series:

Part 1 – Introductory Topics

Part 2 – Environment Setup

Part 3 – React Core Concepts

Part 4 – Creating Components Introduction

Part 5 – React Lifecycle

Part 6 – React Composition

Part 7 – React Router

Part 8 – React Forms

This episode explores the 9th module from this course

Flux

Intro

We can use Flux to handle data flows throughout our application. It’s not so much a framework as a pattern of uni-directional data flows.

Unlike two-way data binding libraries (e.g. Angular 1, Knockout), data flows only in one direction.

This module discusses Facebook’s implementation of Flux, but there are many alternatives available:

• Alt
• Reflux
• Flummox
• Marty
• Fluxxor
• Delorean
• Redux
• Fluxible

Cory says most of these alternatives usually require less code to do the job, often at the expense of clarity of flexibility.

Redux is significantly more popular than, and in my opinion to superior to, Facebook’s Flux:

So my advice is it doesn’t hurt to learn, and is quite useful to learn a bit about Facebook’s Flux, but don’t adopt it until you’ve also seen what Redux has to offer you.

Regardless of your choice of Flux flavour, the purpose of Flux is to make your code easier to reason about and debug.

Cory contrasts Two way binding with the Uni-directional data flow that Flux provides.

With Flux, the view never directly updates the state. It instead fires Actions which go through a workflow before the state is updated. The results of an action are easy and predictable to trace.

Cory says there is a trade-off between the two approaches and uni-directional data flows increasingly pay off as your application grows. And this is what Facebook experienced:

“We found that two-way data bindings led to cascading updates, where changing one object led to another object changing, which could also trigger more updates.

As applications grew, these cascading updates made it very difficult to predict what would change as the result of one user interaction.” – Facebook

Three Core Flux Concepts

1. Actions
2. Dispatchers
3. Stores

Cory gives an example of a delete user action, and describes the work that each of these perform.

Actions

• Encapsulate Events
• Triggered by user interactions and server
• Passed to dispatcher

Dispatcher

• Central Hub – there’s only one per app
• Holds list of callbacks
• Broadcasts payload to registered callbacks
• Sends actions to stores (gets messages from views to stores)

Cory recommends creating a constants file to keep things organized

Stores

Cory discusses each of the following points and more

• Holds app state, logic, data retrieval
• Not a model – contains models
• Can have one, or many, per app
• Registers callbacks with dispatcher
• Uses Node’s EventEmitter
• Have no direct setter methods
• Only accept updates via callbacks registered with the dispatcher
• Is the only thing that knows how to update data

He also describes the structure of a store. Ever store has 3 common traits:

1. Extend EventEmitter
2. addChangeListener and removeChangeListener
3. emitChange

Cory gives an example of a situation where you might want to use three stores in your application, and describes what happens when a user is saved. Finally he highlight a paragraph from the Flux documentation.

Controller Views

• Top level components
• Interacts with stores
• Holds data in state
• Sends data to children as props

Flux Flow in Detail

Cory describes the process that is kicked off by a user being saved:

• Payload sent to dispatcher with type USER_SAVED and the user information as data
• Dispatcher checks for registered callbacks
• Dispatcher sends action payload to all registered callbacks
• Store receives payload
• Store updates and emits change event

Cory explains that although this approach involves more typing, the code is easier to reason about and maintain.

A Quick Chat with Flux

Cory illustrates the Flux process via anthropomorphism.

“Ooh! Shiny new data from the store. I’ll update my UI to reflect this” – React

Flux API

There are only a few important functions in Flux. Cory explains what they are and what they do.

• register
• unregister
• waitFor
• dispatch
• isDispatching

Finally, Cory answers the question “So Is Flux a Publisher-Subscribe Model?”. They are similar design patterns but they differ in two key ways.