For years now, the front-end part of the applications is becoming increasingly important in the development process. This is the reason why engineers are constantly thinking of a way to improve the architecture part of any front-end application.
For years they have been using an old and well-known MVC (Model - View - Controller) approach, but at some point, a decision was made (in one of the largest companies in the world, Facebook) to take a different path.
This is how Flux architecture was invented. But that was not the end of the story. In the future, an engineer named Dan Abramov felt Flux architecture could be simpler and created Redux in 2015.
Again, that is probably not the end of the story, but this time we will focus on Flux and Redux. In this article, we will handle the most important aspects of both and look at the differences - hoping this may help you choose the right approach for your application.
MVC - this is where it all began
We’ll not dwell on the MVC architecture a lot, but it briefly reminds us of the basic principles. First, MVC is a shortcut for Model - View - Controller - three components into which any application is divided:
- Model - this part takes care of the application’s data.
- View - displays the data from the model in the User Interface.
- Controller - this is the interface between the view & model components.
The process is simple - when the controller receives the request from the user, it uses the appropriate model and views with a response it generates.
What is Flux?
Flux is an Architecture that was built around a CQRS concept. CQRS is a shortcut for Command and Query Responsibility Segregation - its main purpose is to separate parts responsible for reading information from the ones that take care of its modification.
Flux is based on the following components:
- Store (or Stores) serves as containers for the application state and logic (Model).
- Action is a component that passes data to the dispatcher.
- The view is similar to MVC - but it’s connected to React components in this context (View).
- Dispatcher - as the name may suggest - coordinates actions and stores updates (Controller).
In Flux architecture, whenever an action is initiated by the user (for example, he clicks on something), the view component creates action. Action can create some new data and send it to the dispatcher, which dispatches the result of the action to the store. In the end, the store updates the state based on the results and sends the update to the view component.
What is Redux?
Now let’s take a look at the Redux library. As mentioned, Redux was invented to simplify Flux. It implements Flux concepts but in a bit different way. It introduces new components, such as
- Reducer - logic that manages data changes in pure functions. It uses the previous state and actions to return the next state and data.
- Centralized store - this is simply a state object that denotes the entire application’s state.
The way Redux operates is simple:
Action is dispatched to the reducer, which updates the centralized store with the data based on the action used. The store will create a new state and send the updated data to the view, which is being rerendered in order to show the update.
Now that we know some basics about both architectural approaches let’s look at the main differences.
- Use cases
Let’s begin with the most obvious part - the suggested use cases for each architecture.
Flux and Redux are similar in one aspect - they both support client-side frameworks and are both front-end architectural approaches. They work very well with frontend frameworks - the main difference being that Redux not only supports React, Vue, Angular, and Polymer but is also very good for Ember, Backbone, and Meteor.
- Data flow direction
Flux and Redux represent the same approach regarding data flow - in opposition to MVC. They encourage unidirectional flow. This gives you much better control over the data.
This is an actual difference between Flux and Redux. Redux uses a single store, and Flux uses a multiple stores approach.
This means that Redux keeps state information in one place of the application, whereas Flux uses multiple stores per application.
You probably wonder what the main difference between a single and multi-store approach is. Data handling is the simplest and most straightforward answer.
When an action is using multiple stores, you must remember to handle it in every store. It’s also a bit harder to manage updates and track what the state includes. In Redux, there is a single store, and all the changes are made through Reducers functions.
- Business Logic placement
Business logic is the most important part of any application. This part allows the business rules to be the actual application.
In Flux, the business logic (changes in the data based on the actions) is handled in the appropriate store. A store is also a place that controls the data access by the public.
On the other hand, Redux handles the logic in the reducer function - a function that receives both the previous state and action - giving a new state in return.
How do Flux and Redux handle debugging?
Flux uses a dispatcher to handle all the actions, and this part of the architecture also allows pretty simple debugging.
As you may remember, Redux does not have this part, so the debugging is handled slightly differently but also pretty easy (some may say, much easier than in Flux).
A single Store maintains the state of the entire app. This makes the debugging process easier. What Redux also offers is logging all the actions leading up to a certain point and a live code-editing option with a debugging feature that enables replaying debugging action.
The way Redux operates is similar to event sourcing principles - making it even more exciting, as event sourcing is a growing approach that is becoming more and more popular.
It’s tough to give one final verdict. The thing we need to remember after reading this article is that Flux is an architectural approach, and Redux is merely an implementation of Flux architecture. This is why they are both pretty similar, and you need to do thorough research to determine which one to choose.
We think Redux is a bit more exciting because of the event sourcing and one-store parts.
If you have any questions or doubts, feel free to reach out to us - we have solid competencies in Flux and Redux and are more than happy and capable of helping you make a good choice for your particular project.
Contact us at email@example.com