The Rise of Flux: How Facebook’s Shift Away from MVC Led to a New Era of UI Architecture
As Flux architecture has been out for several years, the concept of ‘store’ seems to be everywhere: Flux, Redux, MobX, Rematch, Zustand and so many more. I am so used to code under this architecture and these concepts that I wanted to go back and understand what were the alternatives before Flux. I made some interesting and surprising discoveries.
This article won’t be about the alternatives to Flux, but rather about MVC, Flux, and the relationship between them.
To be exact, the topics are -
- The original MVC pattern
- Why Facebook stopped using MVC and created Flux
- Unidirectional vs. bidirectional data flow
- Flux overview
- Is Flux just another variant of MVC?
- Redux vs. Flux
The first UI architectural pattern
The idea of a UI architecture started in 1979 when Trygve Reenskaug introduced to the world the MVC pattern.
What is MVC?
A software architectural pattern that separates an application into three main logical components - Model View Controller.
From the document “The original MVC reports Trygve Reenskaug Dept. of Informatics University of Oslo” :
MVC was created as an obvious solution to the general problem of giving users control over their information as seen from multiple perspectives.
MVC was conceived as a general solution to the problem of users controlling a large and complex data set.
MVC responsibilities
Model - Responsible for managing application domain data
View - Responsible for rendering a UI presentation of the model
Controller - Responsible for handling view events
MVC data flow
This is the complicated part because many people have different ideas about what MVC is.
I began searching for a precise definition of MVC, trying to uncover the exact relationship between its three parts. I wanted to get as close as I can to the original MVC pattern as described in 1979. I found out the following:
MVC by MDN:
MVC by Wikipedia:
Other sources:
A comparison of these diagrams reveals different relationships between the Model, View, and Controller. The obvious question is - does the View update the Model, or does the Model update the View? Maybe they can communicate with each other? The same question can be asked about a Controller and View, or a Controller and Model.
Just to be clear, all the different diagrams might describe a valid pattern or variant of the MVC pattern, but there can only be one original MVC pattern.
Eventually, I found the original document (attached below) written by Trygve Reenskaug, the creator of MVC.
Model - “Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects.”
View - “A view is a (visual) representation of its model. It would ordinarily highlight certain attributes of the model and suppress others. It is thus acting as a presentation filter. A view is attached to its model (or model part) and gets the data necessary for the presentation from the model by asking questions. It may also update the model by sending appropriate messages.”
Controller - “A controller is the link between a user and the system. It provides the user with input by arranging for relevant views to present themselves in appropriate places on the screen. It provides means for user output by presenting the user with menus or other means of giving commands and data. The controller receives such user output, translates it into the appropriate messages and pass these messages on .to one or more of the views. A controller should never supplement the views, it should for example never connect the views of nodes by drawing arrows between them. Conversely, a view should never know about user input, such as mouse operations and keystrokes. It should always be possible to write a method in a controller that sends messages to views which exactly reproduce any sequence of user commands.”
Putting it all together -
This doesn’t mean that parts are directly connected, but that messages are passed between them.
MVC at Facebook
Facebook used to build its UI applications using MVC, but in 2014 something changed. During the Hacker Way conference, the Facebook team announced that MVC was not working for them anymore, and they would be switching to their newly created architecture - Flux.
Why did Facebook switch away from MVC?
According to Facebook, MVC is based on the concept of ‘bidirectional data flow’ also known as ‘two-way data binding’ and MVC therefore doesn’t scale.
What is bidirectional data flow?
Bidirectional data flow refers to data being changed in multiple directions. In MVC, it usually refers to the view being able to change the model and vice versa.
Two-way data binding refers to sharing data between a component class and its template. If you change data in one place, it will automatically reflate at the other end. For example, if you change the value of the input box, then it will also update the value of the attached property in a component class.
Many popular frameworks like Angular.js and Vue support bidirectional data flow.
Why is bidirectional data flow not scalable?
Bidirectional data flow involves many-to-many relationships, which are difficult to track and maintain.
The following diagram was presented during the Hacker Way conference demonstrating an architecture diagram for one of Facebook’s more complex interfaces.
There is just an explosion of arrows. Can you tell if there is an infinite loop here?
The “zombie” unseen messages count
Facebook experienced scalability problems with its MVC architecture as they started to grow and began adding more and more features to the chat system. The chat messaging tool was added to the initial small chat tab, which displays the number of unseen messages and eventually the larger messaging view.
Users complained that the unseen count was showing up, despite there being no unseen messages. Funnily or sadly enough, the Facebook team wasn’t able to fix the bug. As new features were added to the chat, the bug returned with a new edge case.
According to Facebook, the fact that they were using the MVC architecture to build the chat was at the root of the problem.
Flux, an alternative to MVC
In 2014, during the Hacker Way conference, Facebook introduced Flux architecture as an alternative to MVC. Flux is the application architecture that Facebook uses today for building client-side web applications. The main concept of Flux is unidirectional data flow.
Flux architecture consists of four main components -
Action -
- Actions define the internal API of your application
- Actions are simple objects that have a “type” field and some data
The following is an example of some actions within a to-do list:
const deleteTodoAction = {
type: 'delete-todo’,
todoID: '1234',
};
const addTodoAction = {
type: 'add-todo',
todo: {
name: 'buy milk',
description: 'description text'
}
};
- In addition to Views, actions can be dispatched from other sources in the app
Dispatcher:
- The dispatcher receives actions and dispatches them to the stores
- Stores are registered with the dispatcher
- All actions will be sent to every store
Store:
- A store is what holds the data of an application
- The data in a store must only be mutated by responding to an action
- Every time a store’s data changes it must emit a “change” event
View:
- View subscribes to change events from stores
- Data from stores is displayed in views
- Actions are typically dispatched from views
Flux unidirectional data flow
The main difference between Flux and MVC is the data flow direction.
While in MVC the data flow is bidirectional, in Flux the data flow is unidirectional.
The diagram flow:
- Views send actions to the dispatcher
- The dispatcher sends actions to every store
- Stores send data to the views
What does the community think about Flux?
There seems to be a consensus regarding the Flux architecture. There are many articles and discussions on the community forums in support of the concept, especially its unidirectional data flow.
However, I found an enlightening discussion on Reddit regarding Flux and MVC (the original post is attached at the end). Some developers claim that Facebook misunderstood MVC and used it incorrectly, which is why MVC did not scale for them. In addition, some developers believe that Flux is essentially MVC, but with a different name.
And here is Facebook’s Jing Chen response who presented the Flux architecture at the Hacker Way conference:
Is Flux just another variant of MVC?
After reading all the sections above, one can conclude that Flux is not at all like MVC, at least not the original MVC pattern. The concepts of unidirectional and bidirectional are too different.
Facebook makes a valid point: Flux appears to be a completely different architecture from MVC. Nevertheless, it is evident that Facebook did not use MVC properly, or at least not as it was intended.
Redux vs. Flux
In 2015, a year after Flux’s announcement, Dan Abramov released Redux, a brand-new implementation of Flux.
Redux is simply another implementation of Flux.
While it has a distinct implementation from other libraries implementing Flux, such as Flux (the library that implements the Flux architecture created by Facebook and of the same name) and Flummox, it is essentially a library implementing Flux.
When Redux was introduced, the main differences that Redux offered were:
- A single source of truth
- Immutability
- Store as a reducer function
Almost immediately after the announcement of Redux, other implementations of Flux began to adapt Redux’s revolutionary concepts. However, eventually they moved to a maintenance mode in favor of Redux or a similar state management library.
Summary
- According to the original MVC document, MVC is based on bidirectional data flow
- Bidirectional data flow is not scalable
- Flux is based on unidirectional data flow
- MVC and Flux are two different architectures
- Redux is a library implementing the Flux architecture
As a huge fan of state management libraries, I’d love to hear in comments about any interesting libraries you’re working with!
Read more -
- The original MVC reports Trygve Reenskaug Dept. of Informatics University of Oslo
- Redux Origins - online talk at Wix’s guild day
- GUI architecture - Martin Fowler
- MVC by MDN
- MVC by Wikipedia
- Flux concepts
- MVC vs. MVP
- Reddit post (MVC doesn’t scale use Flux instead)
- Dan Abramov - Live React
- Why use redux over facebook flux
