FLUX vs MVC
The internet is abuzz with Facebook’s recently launched Flux, their new pattern to structure client-sided applications. Let’s take a look how the new Flux pattern relates to the earlier used MVC pattern and how it could end up being as useful as the user interface builder, React.
The story behind the model-view-controller(MVC) pattern and how numerous companies and projects have used it in the past is pretty interesting. It is recommended that you go through this brief history because it’s a great way to understand the specific domain that the Flux pattern operates under.
The MVC Pattern
Web developers have been using a lot of model-view-controller (MVC) patterns that have each being doing things a bit differently than the other. But, most MVC patterns typically perform the following core roles:
a. Model: This maintains the behavior and data of an application domain.
b. View: This represents the showcasing of the model in the user interface.
c. Controller: Taking user inputs, manipulating the model and prompting the view to update itself
The core concept of model-view-controller can be formulated by:
1. Separating the presentation from the model – This not only enables the implementation of varied UIs, but also ensures smoother testability.
2. Separating the controller from the view – This is extremely useful for older web interfaces that are not commonly used in most Graphic User Interface (GUI) frameworks.
Problems with MVC
Introduced in Smalltalk-76, the object-oriented, dynamic reflective programming language, MVC is an application pattern that is a legend in its own right as it has been employed for multiple projects ever since 1976. And even in 2015, it has firmly stood the test of time and is being used in some of biggest projects. So, the question arises as to why it should even be replaced! The truth is that MVC didn’t scale well when it came to Facebook’s enormous codebase. Major challenges arose due to Facebook’s bidirectional communication platform, where one change would loop back and have ripple effects across the entire code-base. This made the system fairly complicated and debugging almost impossible.
The Flux Pattern
MVC’s shortcomings posed some serious challenges, and Facebook solved them by incorporating Flux, which forces unidirectional flow of data between a system and its components. Typically, the flow within an MVC pattern is not well defined. Flux however, is completely dedicated to controlling the flow within an application, making it as simple to comprehend as possible.
The Flux pattern has four core roles including actions, storage, data dispatcher and views. Their functions are described below:
a. Actions – These are pure objects that consist of a type property and some data.
b. Stores/Storage - This contains complex data, including the application’s state and logic. One can consider stores as a manager for a particular domain within the application. While Flux stores can store virtually anything, they are not identical to MVC models because these models typically attempt to model single objects.
c. The Dispatcher – This essentially acts as the hubs nerve center. The dispatcher processes actions like user interactions and prompts loops that the storage has registered within it. And as with storage, the dispatcher is quite different from controllers in the model-view-controller (MVC) pat
tern. The difference is that the data dispatcher does not contain a lot of logic within it, allowing you to reuse the samedispatcher across a variety of new and complex projects.
d. Views – These are just controller-views and are also commonly found in most Graphic User Interface (GUI) MVC patterns. They monitor for any changes within the stores and re-design themselves accordingly in real time. Views also have the ability to add new actions to the dispatcher, user interactions included. These views are normally coded with React, but with Flux patterns it’s not necessary to use React. The typical flow of a Flux application can be defined in the below diagram.
It is critical to note that every change that you make will go through an action via the dispatcher.
So how does Flux differ from MVC?
1. The Flow
When it comes to Flux, the flow of the application is vital and these are governed by some strict rules and exceptions that are enforced by the data Dispatcher. In model- view-controller (MVC) patterns however, the flow is not strictly enforced or not enforced at all. This is why different MVC patterns implement their flows differently.
2. Unidirectional flow
As all changes go through the data dispatcher, stores/storage cannot change other stores directly and the same basic concept applies for views and other actions. So, any change has to go through the dispatcher via actions. And MVC’s commonly have bidirectional flow.
3. Stores
Flux stores can store any application related state or data. But, MVC models try to model single objects.
So, Is Flux better than MVC?
The fact that Flux has only recently been launched means that it’s too early to say as its perceived benefits are yet to be vetted. That being said, Flux is very new and innovative and it’s just refreshing that there is now a new pattern that can challenge MVC and its traditional ways.
The best part remains that Flux is extremely easy to understand and comes with minimalist coding, allowing you to structure your app in a more effective manner. This augers well for the future, particularly when React’s programming language is nefarious for coming with a nearly endless huge codebase and an even bigger runtime complexity that turns off a lot of web developers.