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.
Also in this series:
This episode explores the 9th module from this course
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:
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
Cory gives an example of a delete user action, and describes the work that each of these perform.
- Encapsulate Events
- Triggered by user interactions and server
- Passed to 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
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:
- Extend EventEmitter
- addChangeListener and removeChangeListener
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.
- 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
There are only a few important functions in Flux. Cory explains what they are and what they do.
Finally, Cory answers the question “So Is Flux a Publisher-Subscribe Model?”. They are similar design patterns but they differ in two key ways.