Part II. Is Flux the foundation of our architecture?⚡️
Introduction
Hello everyone, my name is Maxim Ivanov. I am a member of the NGXS team and organizer NGXS-Labs. I have been with the team for 2 years and over the years I have learned a lot. Last time we talked about what does NGXS offer for us. Today, we will go back in time and find out how it all began.
History
Before moving on to considering patterns, let’s remember that one of the main goals of frameworks is the state management. It is based on three aspects: state, presentation, actions.
2009–2012
But if you return to the distant past and remember how it all began, It becomes quite clear why AngularJS, Backbone, Knockout have long been forgotten.
The main advantage of the MVC pattern is the strict separation of responsibilities and code reuse. This pattern implied the fact that your model could be changed both from the template and from the controller.
The MVC, which was designed for the server side, was not intended for the client. In fact, the MVC had poor performance for the client.
2013–2015
Therefore, it was obvious that bad practices would be replaced by better ones. And they came just from the world of React.
The first was a Flux. The main feature of Flux was the unidirectional data flow.
This approach makes the data flow predictable and makes it easier to track the causes of possible errors in the application. Flux was based on three aspects: state, view, actions. We could be this easily explain in several stages:
1. For example, the component is going to change something in the view template, it has to send an event with a certain type and transfer data.
2. All business logic and processing was performed in this manager.
3. After we received the new state, it was immediately updated in the store and subsequently updated in our view.
Flux really solved most of the problems of the MVC. Because Flux uses unidirectional state changing. It was disadvantage only that it was impossible to compare the previous state with the new state. It was not clear at what point this happened.
It is clear that any approach has its drawbacks, so Dan Abramov introduced a new implementation of state management and called it Redux.
The Redux concept was different in that you did not need to use multiple stores. Redux uses reducers as a state manager. Reducers are pure functions that receive a new state from actions according to the transferred data.
The classic reducer of our todo state will look like on picture. When we execute an action and send an event to the store, our state changes. In general everything is quite simple.
Well, so why is it so important to use have store?
Everything is very simple, if when developing your application, you want to be guided by such principles as:
- Single data source.
- Change of states only through an action call, and not directly.
- The ability to rollback the state.
- Easy debugging and testing of the application.
2015–next years
Looking ahead, you can easily answer that a concept like Flux in many ways laid the foundation for many of the solutions used in the frontend. In the next article we will briefly compare NGXS and NGRX.
