Let’s go over what this Redux technology is all about. It seems that if you use React, one can’t escape the fact that the application state will need to be properly managed. See, React is fine when they’re small. But once they get big – the state (where data lives) becomes a nightmare to work with. Dealing with many components – you want a way to centralize all of that state.
Enter Redux. Redux is an application that is built mainly to handle state. Note that Redux can be used without React. It can be used alongside JavaScript applications that needs it.
By the way, I struggle with React and Redux. I couldn’t grasp working with the two technologies together. So I decided to take a step back – and learn just Redux. I took Mosh Hamedani’s course and here’s what I discovered.
Building Blocks
So for Redux to work, it needs these 3 building blocks 1) Actions, 2) Store and 3) Reducers.
1) Actions
This is a JavaScript object that describes the CRUD operations for your store. It also contains the “payload” – which is data that is going to change the store.
It needs a “type” property which describes the action. An example type will be when an item is inserted, so a good “type” would be “ITEM_ADDED”. There is also another property called “payload”, which is another object that contains the minimal information about what is getting updated or inserted or deleted.
Check out this example Action Object:
[
{
type : 'ITEM_ADDED',
payload : {
id : 30,
name : 'coffee'
desc : 'drink'
}
},
{
type : 'ITEM_DELETED',
payload : {
id : 25
}
},
{
type : 'ITEM_UPDATED',
payload : {
id : 30,
desc : 'warm clothing'
}
},
]
You see how it contains only the minimal information in the payload. For example, when deleting an item, all you need is the ID.
So you create an action object each time you want to change the store. As mentioned, the action contains the type (what kind of change) and the payload (the actual changes) that you want.
But the Action alone doesn’t change the state. We’ll get to that.
Let’s move on the Store:
2) Store
This is the single source of truth. It’s also a JavaScript object – and it’s immutable. Meaning we can’t edit it directly. In order for us to edit it, we need to call its dispatch() method, and pass in the action.
A store can be as simple as this:
{
User_data : {},
Items : [],
Categories : []
}
But before we can even create a store, we have to have a reducer. Let’s move on to that.
3) Reducers
So these are functions that mutate the store. Typically, you will have a reducer for each “slice” of the store. In the example store above, we should have 1 reducer for “User_data”, 1 reducer for “Items” and 1 reducer for “Categories“.
Note that we don’t call the reducer directly. The store is responsible for calling the reducer, when we call the dispatch() method.
Here is a reducer for the “Items” in our store:
function ItemReducer(state, action){
switch(action.type){
case "ITEM_ADDED":
return [
...state,
{
id :lastId + 1,
name : action.payload.name,
description : action.payload.desc
}
]
case "ITEM_DELETED"
...
}
}
So think of the reducer as the blueprint on what should happen when you pass it an action. It looks at the action type, works with the action payload, and from this logic – returns a new state.
So we now have a general idea of Redux’s building blocks, it’s time to put them together. Here are the steps on what you should do:
Steps:
There is a strict way of putting together a Redux application. This is done to keep the integrity of the store.
- Design store
- Define actions
- Create a reducer
- Create the store and pass in the reducer //by using createStore(reducer)
Once you have the store, you should have access to it’s functions such as:
- dispatch() // function to mutate the store
- getState() // function go get the state
- subscribe() // listen to changes in the store
Notice that there is only 1 method to mutate the store. It’s done this way to make things follow “pipeline” – all changes are done one way and one direction – to make things trackable and “subscribable”.