How can React and Flux help us create better Angular applications?

Gil Birman
Dec 27, 2014 · 7 min read

Facebook’s React and Flux were the most interesting developments of 2014 for angular developers. Not that angular developers should all go jump ship and hop on the React train. But rather, that React and Flux can teach us ways to architect better angular applications. By taking cues from React and Flux, we can create applications that are simpler, more scalable, faster, and easier to test.

Update: This article is now part of a series about Flux and Angular:
PART 1. How can React and Flux Help us create better Angular Applications?
PART 2.
Achieving Reasonable and Scalable Routing in Angular with Flux

For the purpose of this article, I’ve implemented in two different ways a simple example app named color experiment. The first implementation uses standard angular constructs to build a widget that allows you to filter a grid of colors with a directive called ColorSelector. The other implementation uses Flux with angular to build the same widget. Before you continue with this article, please mess around with the color experiment demo for a moment.

This is what the color experiment demo looks like.

React & Flux Concepts

React Concept #1: Stateless Components

Flux Concept #1: Unidirectional Data Flow

However, Facebook engineers recognized that allowing data to flow in two directions created applications that were difficult to reason about. Hence, the concept of unidirectional data flow was introduced. Specifically, Flux says that data should flow down: starting at the topmost component and then down the tree.

So what happens when a child needs to communicate state to a parent component? For this purpose, Flux introduced the dispatcher, which is the only part of Flux that is actually a concretely-defined thing. Below is Facebook’s standard diagram to explain Flux.

To facilitate the unidirectional flow of data, they also introduced Action Creators and Stores. If you’re new to Flux, it’s important to realize that Action Creators and Stores aren’t really concrete classes nor implementations. Rather, they are prescriptions about how certain types of code should be grouped. Asynchronous code goes in the Action Creators. Logic related to mutating the state of an application goes in the Stores.

In color experiment flux, here’s what the unidirectional dataflow looks like:

React&Flux Concept #2: Single Source of Truth

Single Source of Truth also means that we don’t keep copies of state data in various parts of our application that we have to then worry about keeping synchronized. For example, there is just one instance of the colors object stored within the store.

React Concept #3: DOM Diffing

The role of ng-model

However, in color experiment flux, I swapped out the checkboxes for simple divs and because of the unidirectional flow it was unnecessary to use ng-model.

The resulting code is much simpler and easier to manage than it’s two-way-binded alternative. It also doesn’t have to live in the directive’s link function. Instead, I moved it to the store, where all state logic lives in a Flux application:

All of this logic used to live in the directive, but now it lives in the store and the directive is rather dumb.

So should we throw away ng-model entirely? Probably not. I suspect that ng-model will still be handy in use cases which call for validation, but this is something I have yet to really explore in an angular application that utilizes the Flux architecture. My theory is that in order to prevent a directive utilizing ng-model from becoming stateful, we should clone any state data going into and coming out of ng-model, and this would essentially preserve the advantages of using flux (update: check out this response by Wolfram Sokollek, he solves this very nicely). This is similar to the approach used by flux-angular, a flux framework for angular which forces cloning of all data going into and coming out of stores.

The role of ngRoute & ui-router

I have an angular flux-based solution which minimally uses ngRoute along with standard flux concepts to handle application flow and routing at the same time. However the use case it tackles is not terribly complex, so this is another area that I’d like to spend more time exploring.

Update: I’ve written another article that robustly solves Angular+Flux routing.

Where does stuff go? Solved.

  • Asynchronous stuff? In the Action Creator.
  • Stateful mutation stuff? In the Store.
  • Message Passing stuff? Dispatch an action.

Speaking of message passing, what about angular events? With flux, you can still use them, but in a much more restricted domain. Specifically, if you want to broadcast an event from a store after it receives an action and mutates data, you should use the angular event system. For most other messaging situations, the flux dispatcher is probably the way to go.

Visualizing Application Flow

… and here’s what we get with a more complex (but contrived) application:

Notice that in every application, there is a very predictable pattern:

View (white) → Action Creator (orange) → Action (yellow) →Store (blue)

Resources

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store