React Lesson 3: What is Redux

What is Redux? If you know what I do here, then you know that I do not write tutorials around something I already know. In my professional experience, I am just now teaching myself React for the first time. (Professionally, I worked in Vue and other, older frameworks before.) I have literally never used or even researched Redux. So, as is my wont, we get to go on this journey together. I think this is fun. Fresher.

I’ve heard Redux mentioned in the same breath as React dozens of times. It looks like a state management library. It looks like they’re at least attempting to be framework agnostic, maybe, but there is a “React Redux” project written by the Redux team for binding Redux to React. I just read this quote from their front page: “Automatically implements complex performance optimizations, so that your own component only re-renders when the data it needs has actually changed.” I like the sound of that. Let’s explore.

Some questions spring to mind right away, and I may not be able to answer them, but I’ll try to answer some of them. For what kinds of apps is Redux worth its footprint? (More on that next paragraph.) At what point would I actually need to have an entire library for state management? Why is Redux so popular? Why is it specifically so popular for use with React? It is somehow optimal for use with React or is the connection between the two just a happenstance thing that grew over time? Can you use it with some other framework like Angular? (I’ve never heard of anyone doing that, but there are plenty of things you could do but that people don’t do.) Why use Redux over some other state management library?

You will sometimes hear people speak of the “cost” of some code library like Redux. They are almost never talking about a licensing fee. Major libraries are almost always free and open source. They are all backed by corporate sponsors with a business interest in what they provide. What these people mean by “cost” is the file size. Downloading something costs time—the user’s time—and every millisecond makes it more likely the user just goes someplace else. That’s money lost. Nobody in this industry is kidding around when they talk about file size. Be small or bust.

Reading here (https://react-redux.js.org/introduction/why-use-react-redux ) we see the claim that Redux is independent of any framework (Angular, React, Vue, etc) but React Redux is an official binding between the two. If done correctly, this should mean that React Redux is a tiny library that acts as an interpreter between the two libraries, doing the minimal required translations so that Redux just works in a React setting. Before this is over, I’m going to build some kind of React widget that uses Redux (no matter how unnecessary and ill-advised) to see how it works. For now, I think let’s take a look at https://redux.js.org/.

It calls itself a “predictable state container for JavaScript apps.” I like that. Predictable is a way of saying the library doesn’t surprise you, and surprises are by far the most unwelcome thing a programmer encounters in his work. (See also https://en.wikipedia.org/wiki/Principle_of_least_astonishment.)

Another admission: I’ve never used a state management library of any kind before. I have a vague idea I formulated about what they do and why, but I’ve never needed one in my own coding projects, and I’ve never worked on a project professionally that used one either. Actually: at work one time we kinda rolled our own state manager. It was maybe like 1 kb and it suited our needs just fine.

Before actually diving into the docs, here’s what I think they mean by a state manager. I don’t think they’re talking about the tiny little states of individual components. I’m pretty sure they are talking about global state—a big, global singleton object that contains information like whether the user is authenticated and other stuff that might affect the flow, logic, or view of the entire app.

One way to store and handle that kind of information is to just put it in the top-level component and pass the info down explicitly from parent component to child component all the way to the bottom. That can work, but it’s tiresome. Sometimes globals can be OK. We just have to all be really clear about what the globals are.

I’m reading from https://redux.js.org/introduction/getting-started. The web page says Redux is 2 kb. That really is tiny. Good job, guys.

Here are some important basics I see from a first gloss.

They use the word “reducer” to refer to a “pure function with (state, action) => state signature”. A “pure” function is a function in the mathematical sense of the word. The return value follows deterministically from the input values, and it has no side effects. These reducer functions are how state is changed. They are adamant that we never mutate state. We replace state with a new object, which is then our state object. That was the main topic of my React Lesson 2. In that lesson we also saw how this paradigm of state management helps us do things like keeping track of previous states for any reason we might want to do that, such as just looking at them again.

I must say this getting started page (link above) has an embarrassment of resources like I rarely encounter when trying to learn a new library. There are full-source code examples and articles about motivation and videos by the creator of the project and on and on and on. But: having a giant list of options is not always the most helpful thing to get somebody started learning something. Editorial choices and a straight line to follow—those are the reasons people buy books to learn from. Now *I* have to make an editorial choice.

I want to know the motivation first, since that is an option, so let’s read here:
https://redux.js.org/introduction/motivation. This thing seems super-simple. So far I haven’t seen anything that looks innovative. But I’m sure I’ll find it. Libraries don’t just become major successes for no reason. Read that page. It’s short and it doesn’t say much. It’s a preamble. It does mentions some specific influences: Flux, CQRS, and Event Sourcing. Don’t follow those links right now. Those are sidetracks and I’m making an editorial choice to ignore them for now, but here’s a note in case we want to circle back on these later. Our next page to read is this one:https://redux.js.org/introduction/three-principles .

They keep saying “state tree”. I understand what that means in principle, but in action I’m not sure how you would use a tree of states. They probably mean that we can introduce rules for changes propagating down the tree but without changes down the tree requiring any sort of propagation up the tree.. That’s what I’d do anyway.

We’re reading about the “three principles” of Redux. “Single source of truth”. That’s clear enough. “State is read-only”. Here I think what they mean is that nobody and nothing mutates state but itself. State only changes if something emits information to state and state decides to change itself. They make a very bold claim here: “there are no subtle race conditions to watch out for”. I don’t buy that. It’s outside what a state manager can control. Sure, the way state processes messages sent to it can be precise and ordered, but you could still introduce a race condition related to which message gets sent to state first. Oh, and they call these messages “actions”.

The third one is “changes are made with pure functions”.

I’m starting to see how and why Redux is so tightly bound to React. They share a philosophy. If you follow the docs and write React components the way they say you should, then each individual component has its own internal state that follows these principles too.

I can tell you that the way React forces you to handle state is not the way of Vue or Angular. It seems quite idiomatic and even idiosyncratic. Neither Vue nor Angular force you to think of the state of a component as stream of immutable states changing over time. That is very similar to the Angular “Observable”, but Angular doesn’t force this immutable state thing on you in such a heavy-handed way. In Angular, you can just think of state as always being a static, timeless thing with no past. In Vue this line of thinking is so far outside the realm of consideration it just doesn’t translate. In Vue, state just IS in an eternal NOW. Like, “I am that I am.”

Basically, yes, you can mimic any idea in any framework. If you love Vue but for some reason you still want React’s timeful notion of state, you can force that. (I think I just coined that word “timeful” for this.) But the language informs the message. That’s a point I was trying to make in React Lesson 2. React’s heavy-handedness about state informs what you make with React. There’s no easy way to answer the question, “why Angular versus React versus Vue versus something else?” But if you study them all, you will see important differences. You’ll see the influence of different people with very different goals and aesthetics.

I still adore Vue, and I haven’t written a tutorial yet about Vue because I know it. But maybe soon I’ll think up something I don’t know yet and write about that, and I can tell you about Vue in the process.

Enough of that. Let’s check some history. According to Wikipedia, the original authors of Redux are Dan Abramov and Andrew Clark, and the initial release was in 2015. It’s a short and interesting Wikipedia article: https://en.wikipedia.org/wiki/Redux_(JavaScript_library). The usage tells me that “reducer” function is not jargon they invented for Redux. It clearly already meant something in some other context. (Not going to research that right now.) The article also makes it clear that Redux was a response to React, which was initially released in 2013: “Abramov began writing the first Redux implementation while preparing for a conference talk at React Europe on hot reloading.”

Now let’s read this page: https://redux.js.org/introduction/core-concepts. Core concepts. I’m reading it and just came across this quote: “notice how we don’t introduce any magic?” God, I love that, and I like someone who thinks like that. I was just thinking about writing an article about how much I hate magical programming. Like Angular’s dependency injection. You just declare something as an argument for the constructor function, and then somehow it gets inserted into the constructor when the class is instantiated? What the hell is that shit? Burn the witch!

Well, I’ve done some research, but I haven’t written a line of code, and I still think this is a wrap. This will be a multi-parter. Part 2 coming some other time. Probably tomorrow. I’ll put an update right here when it’s written. But we are going to actually write a thing using this library.

[Update: continued in Part 2.]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s