Flux vs. MVC (Design Patterns)

A look at how Facebook’s Flux pattern solves things differently, especially in relation to the Model-View-Controller (MVC) pattern.

Facebook recently released Flux, a new pattern to structure client side applications. In this article I’ll take a look how it relates to the MVC pattern and why I think it could be as interesting as React itself.

In 2011 I looked at the history behind the model-view-controller pattern and how different companies and projects used it. You may want to check it out as it’s a great introduction to understanding the domain that Flux operates in.

The MVC pattern

Historically there has been a lot of MVC patterns that each do things a bit differently. In general most MVC patterns considers three roles:

• Model: manages the behavior and data of the application domain
• View: represents the display of the model in the UI
• Controller: takes user input, manipulates the model and causes the view to update

The core ideas of MVC can be formulated as following:

• Separating the presentation from the model:
  Enables implementation of different UIs and better testability
• Separating the controller from the view:
  Most useful with web interfaces and not commonly used in most GUI frameworks

MVC Problems

MVC is a legendary pattern that has been used for various projects since 1976 (it was introduced in Smalltalk-76). It has stood the test of time and most of the biggest projects still use it today. Why even try to replace it?

MVC did not scale well for Facebook’s huge codebase. The main problem for them was the bidirectional communication, where one change can loop back and have cascading effects across the codebase (making things very complicated to debug and understand).

How does Flux solve this? By forcing an unidirectional flow of data between a system’s components.

In general the flow inside the MVC pattern is not well defined. A lot of the bigger implementations do it very differently (e.g. Cocoa MVC vs. Ruby on Rails MVC).

Flux on the other hand is all about controlling the flow inside the app — and making it as simple to understand as possible.

The core of the Flux pattern

Flux has four roles: actions, stores, the dispatcher and views. Their responsibilities can be defined as following:

• Actions are simple objects with a type property and some data. For example, an action could be {“type”: “IncreaseCount”, “local_data”: {“delta”: 1}}
• Stores contain the application’s state and logic. The best abstraction is to think of stores as managing a particular domain of the application. They aren’t the same as models in MVC since models usually try to model single objects, while stores in Flux can store anything
• The Dispatcher acts as a central hub. The dispatcher processes actions (for example, user interactions) and invokes callbacks that the stores have registered with it. The dispatcher isn’t the same as controllers in the MVC pattern — usually the dispatcher does not have much logic inside it and you can reuse the same dispatcher across projects
• Views are controller-views, also very common in most GUI MVC patterns. They listen for changes from the stores and re-render themselves appropriately. Views can also add new actions to the dispatcher, for example, on user interactions. The views are usually coded in React, but it’s not necessary to use React with Flux

The general flow of a Flux application can be defined as following:

The most important thing to note is that every change goes via an action through the dispatcher, illustrated like this:

So how is Flux different from MVC?

• The Flow of the app is essential to Flux and there are very strict rules that are enforced by the Dispatcher. In MVC the flow isn’t enforced and most MVC patterns implement it differently
• Unidirectional flow: Every change goes through the dispatcher. A store can’t change other stores directly. Same applies for views and other actions. Changes must go through the dispatcher via actions. In MVC it’s very common to have bidirectional flow
• Stores don’t need to model anything and can store any application related state. In MVC models try to model something, usually single objects

Code examples

In the next section I’ll show a simple counter example using a Cocoa’s MVC pattern and one using Flux. They are both implemented in CoffeeScript.

These examples should make it easier for you to understand how the code works like and how the general structure is.

Cocoa’s MVC

Should be pretty straight forward. A lot of other GUI MVC’s follow a similar convention like Cocoa’s.

Illustrated the flow of the Cocoa example looks like this:

Flux and React

This below code isn’t tested, but it should give a clear idea of how the different roles work like inside the Flux system.

Illustrated the Flux flow looks like this:

Is Flux better than MVC?

We are still very early in the process to determine this. This said, it’s awesome that we have a new pattern that challenges MVC and the old way of doing things. Given that this pattern comes from Facebook is a great sign, since they have smart people working on this and their codebase is huge and spread around many different products.

At Doist we are using Flux and React for a larger project and the codebase so far looks very clean and is a pleasure to work with.

In general, I am more impressed with Flux than with React. The reason is that Flux is very simple to understand and there is almost no code for it—it’s just a way to better structure your app. React meanwhile has a huge codebase and a huge runtime complexity that I am not a huge fan of.