An Unforgettable Way to Learn Redux — The Visual Guide
The following is a visual guide to learning Redux. One focused on the core Redux principles explained with memorable associations and custom illustrations.
Ready?
Here we go!
Consider an event you’re likely conversant with — going to the bank to withdraw cash. Even if you don’t do this often, you’re likely aware of what the process looks like.
Story time.
You wake up one morning, and head to the bank as quickly as possible. While going to the bank there’s just one intention / action you’ve got in mind i.e to WITHDRAW_MONEY.
Let’s be clear on that. You want to withdraw some money from the bank. That’s all.
Here’s where things get interesting.
When you get into the bank, you go straight to the cashier to make your request known, right?
Wait, you went to the Cashier?
Why didn’t you just go into the bank vault to get your money?
After all, it’s your hard earned money.
Well, like you already know, things don’t work that way. Yes, the bank has money in the vault, but you have to talk to the Cashier to help you follow a due process for withdrawing your own money.
The Cashier, from their computer, then enters some commands and delivers your cash to you. Easy-peasy.
Now, how does Redux fit into this story?
We’ll get to more details soon, but first, the terminologies.
1. The BANK VAULT is to the bank what the REDUX STORE is to Redux.
The bank vault keeps the money in the bank, right?
Well, within your application, you don’t spend money. Instead, the STATE of your application is like the money you spend. The entire user interface of your application is a function of your state.
Just like the bank vault keeps your money safe in the bank, the state of your application is kept safe by something called a redux STORE. So, the STORE keeps your “money” i.e state, intact.
Uh, you need to remember this, okay?
The Redux Store can be likened to the Bank Vault. It holds the state of your application — and keeps it safe.
This leads to the first Redux principle:
Have a single source of truth: The state of your whole application is stored in an object tree within a single Redux store.
Don’t let the words confuse you.
In simple terms, with Redux, it is is advisable to store your application state in a single object managed by the Redux STORE. It’s like having ONE VAULT as opposed to littering money everywhere along the bank hall.
2. Go to the bank with some ACTION in mind.
If you’re going to get any money from the bank, you’re going to have to go in with some intent or action to withdraw money.
If you just walk into the bank and roam about, no one’s going to just give you money. You may even end up been thrown out by the security. Sad stuff.
The same may be said for Redux.
Write as much code as you want, but if you want to update the state of your Redux application (like you do with setState in React,) you need to let Redux know about that with an ACTION.
In the same way you follow a due process to withdraw your own money from the bank, Redux also accounts for a due process to change/update the state of your application.
Now, this leads to the Redux principle #2.
State is read-only:
The only way to change the state is to emit an action, an object describing what happened.
What does that mean in plain language?
When you walk to the bank, you go there with a clear action. In this example, you want to withdraw some money.
If we chose to represent that process in a simple Redux application, your action to the bank may be represented by an object.
One that looks like this:
{
type: "WITHDRAW_MONEY",
amount: "$10,000"
}In the context of a Redux application, this object is called an action! It always has a type field that describes the action you want to perform. In this case, WITHDRAW_MONEY
Whenever you need to change/update the state of your Redux application, you need to dispatch an action.
Don’t stress over how to dispatch an action yet. Just understand what the principle says.
Programmatically, here’s how a store is created:
import { createStore } from "redux"; //an import from the redux lib
import reducer from "./reducers"
const store = createStore(reducer);//see the next section for how the imported reducer is created
3. The CASHIER is to the bank what the REDUCER is to REDUX
Alright, take a step back.
Remember that in the story above, you couldn’t just go straight into the bank vault to retrieve your money from the bank. No. You had to see the cashier first.
Well, you had an action in mind, but you had to convey that action to someone, the Cashier, which in turn communicated (in whatever way they did) with the vault that holds all of the bank’s money.
The same may be said for Redux.
Like you made your action known to the Cashier, you have to do the same in your Redux application. If you want to update the state of your application, you convey your ACTION to the REDUCER — our own Cashier.
This process is mostly called DISPATCHING an ACTION.
Dispatch is just an English word. In this example, and in the Redux world, it is used to mean sending off the action to the reducers.
The REDUCER knows what to do. In this example, It will take your action to WITHDRAW_MONEY and ensure you get your MONEY.
In Redux terms, the money you spend is your STATE. So, your reducer knows what to do, and it always returns your NEW STATE.
Hmmm. That wasn’t so hard to grasp, right?
And this leads to the last Redux principle:
To specify how the state tree is transformed by actions, you write pure reducers.
As we proceed, I’ll explain what a “pure” reducer means. For now, what’s important is to understand that, to update the state of your application (like you do with setState in React,) your actions must always be sent off (DISPATCHED) to the reducers to get your NEW STATE.
Never Mutate State Within the Reducers.
In very simple terms, a reducer is just a function that takes in state and action , and returns a new state
export default (state, action) => {
return state;
};When returning state from reducers, there’s something that may put you off at first. However, if you already write good ReactJS code , then you should be familiar with this already.
You should not mutate the state received in your Reducer. Instead, you should always return a new copy of the state.
Technically, you should never do this:
export default (state=[], action) => {
state.push('new value');
return state
};This is preferable:
export default (state=[], action) => {
return [...state, 'new value']
};Instead of mutating (or changing) the state received from the reducer, I am returning a new array. This array has all the values of the previous state array, and also appends the ‘new value.’
Thanks to the ES6 spread operator, [...state, 'new value']
Every Reducer you write should be a pure function with no side-effects i.e No API calls or updating a value outside the scope of the function.
Got that?
Hopefully, yes.
Conclusion
With this analogy, you should now have an idea of what the most important Redux actors are: THE STORE, THE REDUCER, and an ACTION.
These three actors are pivotal to any Redux application. Once you understand how they work, the bulk of the deed may already be done.
This is an excerpt from my Redux books. If you loved it, go check it out.
Happy coding!
Originally published in Zeolearn.
