What is Flux Architecture? Why Facebook used it? and the Comparison with MVC architecture.
Hi, this is the basic introduction about the Flux Architecture. In this article we will discuss about the use of flux architecture, Why Facebook used it and the comparison with the MVC Architecture.
What is Flux Architecture?
Flux is an architectural pattern proposed by Facebook for building SPAs(Single Page Applications). It is not any framework, it is just the architecture or the pattern to make client-side web applications. It was designed at facebook along with React view library.
The Details and Story of Flux Architecture
The article of Jing Chen, the Original Creator of Flux stated that the Facebook was facing some problems in their application and Facebook came to the conclusion that the MVC structure is flawed and it is not able to scale up their needs. So, the Facebook decided to use the different approach, and then the Flux Architecture is introduced.
Facebook stated that the MVC is good for small applications but when it is used in large and complex applications then it fails and the following diagram is for MVC structure.
According to it, when the user calls an action, controller handle it and calls a method inside the model which can lead to re-rendering the one of the view. But in such big applications it is difficult to understand and debug the bidirectional data flow between models and views, so they introduced the Flux Architecture which is unidirectional and proposed the following Flux Design.
Now, according to this flux architecture there are some major parts of the architecture. So, first lets discuss them.
Action — Action is nothing but just a function which a user calls through the view layer of the application to fire some updates on the view. And the updates are done by changing the data on the view, by calling any web API through the actions. These called actions are passed to the dispatchers.
Dispatchers — It is basically the manager of the whole process. It take actions and broadcast it to all the available stores to update the states of the view. It is the central hub and registry of the callbacks of the application and call the callbacks in a given order and passes the data to the stores.
Store — It acts as the Manager for the application state for which a Store is created. It stores both domain state and User Interface state. And these stored states can be retrieved by just passing an action to the dispatcher. It listens to all the actions and decide to act according to the actions. And then this data which is requested by the action is retrieved and update the view layer of the application for which the action is called.
View — It is nothing but just the User Interface component which is responsible to render the data on the UI and to handle the events based on the user. Some view layers connect to the actions and dispatchers which are called containers and some do not connect to the actions and dispatchers which is the presentation views.
Now, lets sum up the above diagram into a short note.
From the view layer the user calls the action and action passes to dispatcher and dispatcher passes to the store and store updates the view layer and this cycle goes on.
This unidirectional structure shows that the architecture is simple and the latest version of the data is always presented by the view layer of the application.
Why Flux Architecture?
As discussed above that MVC structure is bidirectional, that controller in between interact with both Models and Views and in a large application it become tough to debug and handle the data where there are many nested components in which the data flow can become very fussy.
There is no such link in flux and there is only one store for all the components in the application and the data can be retrieved from the store at the parent component and can be easily passed to its child components that is why it is easier than the MVC structure and can be preferred for the large web application.
