In previous chapters, we have learnt about how to create custom components, DOM interaction with React, and how to use JSX with React, which would have given you enough clarity on React and it's variations with different platforms with practical examples such as the Add Ticket form application. Now we are going to go to an advanced level which will give you further understanding about state management in a JavaScript application.
As we know, in Single Page Applications (SPAs) when we have to contract with state and time, it would be difficult to handgrip state over time. Here, Redux helps a lot. How? Because in a JavaScript application, Redux is handling two states: one is the data state and the other is the UI state and it's a standard option for SPAs. Moreover, bear in mind that Redux can be used with AngularJS, jQuery, or with React JS libraries or frameworks.
What does Redux mean? In short, Redux is a helping hand to play with states while developing JavaScript applications.
We have seen in our previous examples that data flows in one direction only from the parent level to the child level and it is known as unidirectional data flow. React has the same flow direction from the data to components so in this case it would be very difficult for two components in React to properly communicate.
We can see it clearly in the following diagram:
As we can see in the preceding diagram, React is not following the direct communication of two components, although it has a feature to provide provision for that tactic. However, this is deemed as bad practice because it can result in inaccuracies and it's a very old way of writing, which is hard to comprehend.
But that doesn't mean it's impossible to achieve it in React, as it gives an alternative way to do so but, according to your logic and within React standards, you have to manipulate it.
To achieve the same with two components that do not have the relationship of parent and child, you have to define a global event system where they communicate; Flux could be the best example of this.
Here Redux comes into the picture, as it provides a way to store your all states into a place from where components can access it and that place is called the STORE. In simple words, whenever any component finds any changes, it has to dispatch to the store first and if other components require access, it has to Subscribe from the store. It cannot directly authorize communication with that component, as shown in the following diagram:
In the preceding diagram, we can see that the STORE is pretending to be an intermediary for all kinds of state modifications within the application and Redux is controlling direct communication between two components through the STORE, with a single point of communication.
You might think that communication between components is possible with other strategies but it's not recommended as either it will cause faulty code or it will be hard to follow:
So now it's very clear how Redux makes life easier by dispatching all state changes to the STORE rather than communicating within components. Now components have only to think about dispatching state changes; all other responsibilities will belong to the STORE.
The Flux pattern does the same thing. You might have heard that Redux is inspired by Flux so, let's see how they are similar:
Comparing Redux and Flux, Redux is a tool whereas Flux is just a pattern that you can't use to plug and play, and you can't download it. I'm not denying that Redux has some similarities to the Flux pattern but it's not 100% the same as Flux.
Let's look at a few differences.
Redux follows three guiding principles, as shown in the following descriptions, which will also cover the differences between Redux and Flux.
We have seen in the earlier diagrams that the store is pretending to be an intermediary for all kinds of state modifications within the application and Redux controls direct communication between two components through the store, acting as a single point of communication.
Here the difference between Redux and Flux is: Flux has multiple store approaches and Redux has a single store approach.
In the React application, components cannot change state directly but they have to dispatch changes to the store through actions.
Here, the store is an object and it is has four methods as follows:
store.dispatch(action)store.subscribe(listener)store.getState()replaceReducer(next Reducer)
You might be aware about get and set properties in JavaScript: a set property sets the object and a get property gets the object. But with store methods, there is only the get method so there is only one way to set the state which dispatches a change through actions.
An example of JavaScript Redux is shown in the following code:
var action = {
type: 'ADD_USER',
user: {name: 'Dan'}
};
// Assuming a store object has been created already
store.dispatch(action);
Here, an action means dispatch(), where the store method will send an object to update the state. In the preceding code snippet, the action takes type data to update the state. You can have different designs to set your action according to your component's needs.
Reducer functions will handle dispatch actions to change the state as the Redux tool doesn't allow direct communication between two components, so it will also not change the state but the dispatch action will be described for the state change.
In the following code snippet, you will see how the Reducer changes the state by allowing for the current state as an argument and returning a new state:
Javscript:
// Reducer Function
varsomeReducer = function(state, action) {
...
return state;
}
Reducers here can be considered as pure functions. The following are a few characteristics to write Reducer functions:
- No outside database or network calls
- Returns values based on their parameters
- Arguments are immutable
- The same argument returns the same value
Reducer functions are called pure functions because they do nothing except purely return a value based on their set parameters; they have no other consequences.