An Easy and Fun Guide to Redux — Intro and Immutability

Photo by Kelly Sikkema on Unsplash

Hi!

I must admit that I am quite late to the party, but I am quite enjoying my journey in React/Redux universe. One thing, however, always bugs me: most of the online tutorials about React/Redux are seems like a tour de force of all the packages, tools and concepts in the React/Redux ecosystem. Although, I sincerely respect and admire the effort they put into these but such an approach doesn’t suit me well. I believe people learn in different ways. Some prefer the whole picture approach, while others piecemeal. This guide takes the second approach. In each chapter, we build a layer of concepts, focusing on a single framework/tools or particular functionalities of it, building the foundation for the next. Also, I intend to do it in most unofficial, fun way loaded with practical examples.

In this chapter, we would be just covering the basic introduction of Redux and in-length discussion of Immutability. We will end with bare essential setup required for redux. Other than that, there won’t be any code specific to redux in this chapter. We will do that from the next chapter.

So what’s Redux?

From the landing page of redux.js.org :

A predictable state container for JavaScript apps.

Let’s decipher this cryptic definition.
A state is simply an object containing your app’s data in one place. The container is the storage where this state is kept. For those familiar with RDBMS like MySQL, container loosely equals database and state the data in it (say a row in the table). However, there is a unique restriction: State must be immutable. In our RDBMS analogy, it’s somewhat like creating a new row for each change rather than editing an existing one. Let’s detour a little to understand the concept of Immutability further.

So what’s Immutability?

Rather than bore you with exact definitions, let me explain it with the following set of examples:

Chess Vignette
Imagine if you are punished to record a boring chess game. You have two options:

• note each move (e.g. King e1-e4)
• take a snap of the board after every move like a lazy, spoiled brat

Of course, all of you whose childhood was disciplined by the economy of resources would go for the first option.

But you are now dealt with another punishment. After the completion of the game, you may be required to set up the board to any particular move in the game. Now, which approach of recording game do you think would have made life easier for you?

For the responsible first approach, you will have to start from an initial board each time and executing all the moves till the required one (or do some clever relative slicing of moves]. For the irresponsible second approach, you could just take out the snap of given move and set up the board immediately. It pays to be a spoiled brat sometimes.

The first approach here mutates the existing state of the board on each move, whereas the second approach gives us an immutable snapshot at every move. The immutable approach, although being more wasteful of resources, provides us with following cool benefits :

• The capability of easily rolling back to any point in time. This is what predictability meant earlier. We can reproduce any state (for any move) at will with surety.
• Ease of maintenance and reducing the risk of errors. There might be a possibility we record one of the moves wrong. This might cause confusion for all further set of moves. We might need separate book-keeping to add additional surety. (Most modern systems use special audit tables for this purpose, which normally keep both new and old records for each possible change, and are themselves immutable (changing existing audit record is a big NO)).

Coming back to JavaScript, let’s go through an example. Let’s say you have the following array of users, with each item containing the user’s name, email, and age. You later realized that you had entered the wrong age for the user John Galt. If mutations are allowed, you would change the age directly on the original object. In the immutable approach, you would rather return a fresh copy of users. You now need to send an apology email to this user. Thus, you need to identify him first. Below, we show the code samples for both the scenarios.

Mutable Version

Immutable Version

Clearly, we see some immediate benefits for the second approach:

• Original records have not tampered. So let’s say if John Galt disapproves of our change, we can immediately roll back to his original record.
• Identifying the record which changed is super easy. This is because we now need to just check for object reference rather than delving deeper in it.

I hope these examples would have made the basics of Immutability quite clear, especially its benefits. Also, we now a better understanding of each of the cryptic terms in the terse definition of Redux and it’s the relationship with Immutability.

Bare-Bone Redux setup

I will now end this chapter with the basic setup required for our future Redux experiments.

Few key points about the setup:

• We would focus only on the very basics of redux here. We won’t be dealing with any starter-kits, non-essential tools like Webpack or other libraries like React except some bare essential.
• I believe you have Node/NPM already set up on your system and are familiar with common ES6 features. If not, don’t worry. Following links will get you started:

As promised, I won’t be adding loads of dependencies or tools. Only extra packages required would be those needed for babel-node. babel-node is quite similar to the node, except that it supports all missing ES6 features in node including ES6 imports. You can even avoid this and just install the redux package. You may need to do a minor modification to code samples to use Node’s CommonJS module. Just run following commands:

cd app 
npm init npm install --save-dev @babel/core @babel/node @babel/preset-env 
npx babel-node index.js --presets=@babel/preset-env

Or you can pull this repository and just do

cd medium-redux 
npm install

Next Chapter: Actions, Store, Reducers, and Pure Functions

Please share your valuable comments, suggestion or criticism in response, or applaud/share if you liked the article. You can also follow me for updates on future chapters.

Happy Hacking!

Originally published at unprogrammer.com on December 13, 2018.