Hi, I took this course on Front-End Web Development with React by The Hong Kong University of Science and Technology, so this is a gist of that course.
This Blog is pretty Theoretical, So kindly refer for more information links along with documentation of Redux.
Prerequisites would be HTML, CSS , Bootstrap and basic JS
Very often, you see yourself repeatedly solving similar problems. If we have a well-specified documentation of how to solve these problems, why keep reinventing the wheel every single time? So that is where the software engineering’s design pattern concept originates. Sometimes, you also see people referring to this as an architecture pattern.
In the MVC framework, the model manages the behavior and data of the application domain. And the model responds to requests for information about its current state. So, typically when the view wants to render, or the view wants to update itself, it might query the model in order to obtain information, so that it can be rendered appropriately to the user. The model also will respond the requests for change of its state. This is usually done through the Controller. In an event-driven system, the model also can be configured to notify observers. So, viewers can register themselves as observers for the model and so when the model is updated, the views will be automatically triggered to update themselves based on the change to the model state.
The view itself, is concerned with presenting the information to the users in a user interface element. In such a way that it facilitates both the presentation of information to the user and also enables the user to interact with the application. So, the view may represent one representation of the model state.
Q.What is the controller in the MVC framework?
The job of the controller is to receive information from that view. So any user interaction that is formed will be captured and then passed on to the controller in order to act on these user interactions. And it is the job of the controller then to initiate a change of the state of the model if it is required in this particular situation. So, the controller will appropriately cost the change of the state of the model
The Model View View-Model approach is in some sense, a derivative of the Model-View-Controller approach. You have the model that represents the business logic and the data for your application. From the model, you derive a View-Model, which encapsulates that part of the information that is required for rendering a specific view. So the View-Model is the abstraction of the view, that exposes the public properties and the various comments that are available. So this provides a declarative data binding.
The simple React approach that we have taken with one root component that is holding the entire state of the application will not scale in that situation. So it is better to move that skate off your application into its own separate unit in some way. And this is where the model view controller approaches it that we just talked about might come to our help. Because in the MVC approach we see that the model has captured the entire state of your application and any changes that you want to make to the model from the view will have to go through the controller to the model. And then changes to the model may result in the views or some parts of the views being re-rendered. Now, the MVC of course is a wonderful approach and has been very effectively used for many web applications.
Q.Does MVC work for React?
Now when React started out, React was touted as the V in the MVC. And that was the way it was being approached earlier. It has gone beyond being a simple rendering of the view and you see a complete React application being developed.
But if you do so, you can easily have a fully functional React application. But that doesn’t scale very well. And this is where you want to move to a full fledged MVC approach, where you capture the entire state of your application, move it into a model, and then let that dictate how the views are being rendered.
Now, the MVC approach when used by Facebook, they encountered certain issues with the MVC approach. Now, there is a very well presented discussion in a talk given by Facebook on why they faced issues with using the MVC architecture in some of their applications. With the issues like cascading updates where change in one model may result in that causing a change in another model and which causing a change in another part of the model and so on. And this cascading updates of the model state pretty soon becomes very difficult to handle. And so they found that this approach of the MVC approach doesn’t work very well with their kind of applications, especially things that they developed with React. And that is where they came up with their own approach called the Flux architecture.
Q.What exactly is The Flux Architecture?
It is a suggestion idea or a pattern for you to organize your code, and not necessarily the only way of doing things. But, they found that the Flux approach works very well for applications like what you developed with React.
Now, what is the salient feature of this Flux architecture or the Flux approach for developing applications? In this, one of the salient features is unidirectional data flow. The problems that they encountered with MVC was the fact that the updates, as we see lead to a cascading flow of updates within the models, and becomes a tangled web, which becomes untenable after a period of time. And so this is where they decided that all updates have a unidirectional flow. So here the central unit for your architecture is the store. In the Flux architecture you could have multiple stores,
Introduction to Redux
Redux derives a lot of its ideas also from the Flux architecture but it is a realization of the Flux architecture. Now, let’s talk about Redux, and how we can make use of it with a react application. Now, Redux was proposed by Dan Abramov. In one of his talks, in Riyadh, Europe, a project where he was trying to demonstrate ideas about time-travel debugging, and so on, and so he created this framework to demonstrate his idea, and then it ended up being very popular, as a Flux-like approach for a react application. Inspired by all these, Redux was suggested as an approach for structuring your react application.
Redux is a general approach that supports a way of managing store, unidirectional flow that is characteristic of the Flux architecture and much more.
Redux, the reason for adopting something like Redux is that it makes state mutations predictable. Also, Redux supports things like time-travel debugging, we will see that there is a consistent way and you can even observe how your state is being changed and there is a consistent way that you modify the state and so on. Because when you adopt the Redux architecture for your react application, it becomes even more easier to handle the states.
The three main principles of Redux as stated by Dan Abramov,
- The first principle that he states is that in Redux there is a single source of truth or there is a single state object tree within a single store. The Flux architecture allows you to have multiple stores that need to be coordinated together by the dispatcher, and when it dispatches the actions to the stores, all these stores need to update themselves. In Redux, there is a single store. The single store has a single state object tree within the single store, and so that becomes the single source of truth for your applications, be it react or angular, wherever you apply Redux
- Second, the state is read only. Meaning that you can only do gets on the states. So, only getter operation source supporter of state by the store. Any changes to the store should be done only through actions. Again, this comes back from the Flux approach that we have seen. The uni-directional data flow approach that we have just seen in the previous lecture.
- The third part is that any changes that you make to the state are made by only pure functions, what in Redux terms are called as reducer functions. Now, what does this pure function do? The pure function takes the previous state of your application, and the action that is specified, and given the previous state and the actual that is specified, it’ll generate the new state for the application. When the next state or the new state is returned, this new state will not be a modification of the previous step. Previous state will remain as such. But the pure function will return in new state, which is derived from the previous state, but then it’ll create a new state in return. So, there is no mutation of the previous state. Now, within your store, you will store this next step. So your next state of your application will mutate to the next state. Again, because of the use of the pure functions, the immutability of the state is preserved.
For more information,
The Redux Approach
The Redux approach which uses a single store and a single state tree makes it easy for us to implement a few things. Logging of changes to the state is very easy. Now, as you saw because we use pure functions, the next state is always generated from the previous state, but the next state does not change the previous state directly. The pure function returns the next state. So, you can track all the states of your application as they change, and you can log the changes.
So for example, if you encounter a bug, you can walk backwards and then check through the state changes to see how you arrived at the current state and if there was something that was wrong in the way the state was changed. So that allows you to do undo operations so if you don’t want to process the change that you’ve done, it is very easy to support undo. It comes naturally in react as we will see there. State persistence comes in, and then also time-travel debugging also comes to your aid.
Now, here in Redux, the dispatch also is considered part of the store. So, your action is dispatched into your store. The store then uses the dispatch of the previous state and then sends this as input to the Reducer functions. The Reducer function will return the state from these two inputs, and the next state is then stored in your store. And so, that is how your store gets updated. The views themselves are watching the store and any changes to the state will result in the emission of the change to the view and when the view notices the change, the view will go and get the state. And then, if you may generate an action in response to the user’s interaction with the user interface component and so on. So now, let’s examine a few of the Redux concepts now.
The reducer as you see is a pure function that takes the current state and action and generate the next stage of your application. Now, the update to the data is done immutably, if you have an object you won’t change that directly, but instead you derive a new object by copying the previous object and then generate a new object as a copy with the modification applied. You generate a whole new object from the previous object. That is what the preserving the immutability of the objects means.
Q.What exactly is the Redux store?
The store becomes the storehouse for your application state, and any business logic that modifies the application state. So the store encompasses this whole thing, and the only way you can modify your application state within the store is by requesting the store. You don’t have any setters that the store make available to you.
- The dispatch method is where you will supply the action object and then specify what changes you want to make to the state.
- The getState method, to get the updated state from your store.
- Callback function that will be run every time an action is dispatched. So, the dispatching of an action will result in an update to the state. And then, that you can subscribe to the changes and then watch the changes. And you can use getState to get the updated state from your store.
When the store updates its state, the store will emit a change which the controller views will watch for. Whenever a change is emitted, then the controller views will go back and be able to get the updated state. And this, in turn, may result in re-rendering of parts of your views or parts of your components within your React application. So that is how the data flows. But again, it is a unidirectional data flow. Now the views cannot directly change the store. If a view needs to change anything in the store, then, this is the approach that they expect you to take.
So any change that you want to make in your store because of user’s interaction with any particular view within your application, will have to be reflected back to the dispatcher in the form of an action. Now the actions themselves support what I call action creators.So new actions that are initiated will propagate through the system in response to the user interactions. And this will be delivered to the dispatcher, and the dispatcher becomes the center unit that controls all the changes and mediates to ensure that changes to the store are sent through it. There is no other way for you to change the state of your application. So this approach where there is a unidirectional data flow, any changes have to go through the dispatcher, and then be sent to the store. And changes to the store will reflect into your controller views are by the store emitting the change and then the controller view’s then pulling in their changed state through getter operations on the store.
For more information,
One thought on “Introduction to React-Redux”