The Flux Architectural Pattern
by LUCKY AMADI
Last updated
Was this helpful?
by LUCKY AMADI
Last updated
Was this helpful?
Image from
The Flux architecture pattern which is more of a development pattern than a framework is a frontend development pattern introduced by Facebook for building single-page applications (SPAs).
The idea behind flux was to solve the problem of scalability while building an application using the MVC pattern on the client-side.
MVC Pattern (fig. 1)
The diagram (fig. 1) above shows how data is being passed around the app in using MVC architecture, but taking a deeper look into what it will look like in a very large application with several models and view components. We will notice that it becomes too complicated as the application grows very large and this makes it quite difficult to manage how data is being passed to all the components and their relationship with one another.
The Flux pattern solves the scalability issue by using unidirectional data flow to pass data among the different component views in the app. In this case, the application is divided into store, dispatcher, views, actions/action creators. When a user interacts with the view, the view dispatches an action through the main dispatcher to the store where all the application data are held and only update the target view with the needed information from the store. The Flux development pattern works perfectly fine with the React declarative style of programming.
THE STORE
The store is responsible for state management across the entire app and sends data to update the view based on the dispatch it receives. Store and state are different concepts. The State is the data value. A store is a behavior object that manages state through methods. By means of a switch statement, the store sends information to the view component that needs it based on the dispatch type.
THE DISPATCHER
This is an object that broadcasts an action type to the store in order to update the state of the app. It dispatches an action type and can also carry a payload in a case where a new set of data is to be passed to the store to update the state of the app.
THE VIEW
This is the user interface component and determines how the user interacts with the application. They are the user interfaces that listens to the user events and re-render in when their state changes. The view can be classified into presentational views and container views. The container views are connected to the store, while the presentational views are not. React provides the kind of composable and freely re-renderable views we need for the view layer. Close to the top of the nested view hierarchy, a special kind of view listens for events that are broadcast by the stores that it depends on. We call this a controller-view, as it provides the glue code to get the data from the stores and to pass this data down the chain of its descendants.
ACTIONS
Actions are methods exposed by the dispatcher to trigger a dispatch to the stores and most times comes with a payload of data. The action’s creation may be wrapped into a semantic helper method which sends the action to the dispatcher. Actions may also come from other places, such as the server. This happens, for example, during data initialization. It may also happen when the server returns an error code or when the server has updated to provide to the application.
CONCLUSION
Flux is the Frontend architecture that Facebook uses for building client-side web applications. It complements React’s composable view components by utilizing a unidirectional data flow. It’s more of a pattern rather than a formal framework, and you can start using Flux immediately without a lot of new code. You can check the repo
