State Management with Redux & MobX

Single State Store & Reducers

Steve Kinney

Steve Kinney

State Management with Redux & MobX

Check out a free preview of the full State Management with Redux & MobX course

The "Single State Store & Reducers" Lesson is part of the full, State Management with Redux & MobX course featured in this preview video. Here's what you'd learn in this lesson:

Steve introduces the single state store in Redux, a JavaScript object which contains the application's state and is modifiable through the usage of functionally pure reducers.


Transcript from the "Single State Store & Reducers" Lesson

>> Steve Kinney: Terminology out of the way, we're good to go on that front. We're gonna talk a little bit about Redux outside of React, right? We'll understand exactly how Redux works all the way through. And then we will then worry about bringing it into React. So what is Redux, like I said, we'll talk about outside of React.

It's basically, you take the entire state of your application, and store in one big old JavaScript object. If that sounds insane to you, it's actually, Redux gives you a bunch of helpers to make this manageable and brings a sane approach to it. One of the reasons why this is really cool to have it in one plain old JavaScript object is, theoretically, you could build a tooling to, and we actually use this a lot in our testing with Cypress and stuff along those lines.

You can basically take an entire state of the application, take that one object. Serialize it using JSON stringify, and then rehydrate the entire state of your app to get exactly that state back again, right? It's totally separate from your UI, so you're not managing any state in React except maybe input fields or stuff along those lines, ephemeral state that doesn't really matter.

And we're working right now in building some of the tooling to basically allow support to try to get one of those JSON data structures from our customers if they're having a problem. Where basically now, instead of when we get a customer-found defect, and we're trying to recreate the bug, can't do it, right.

We could actually literally take the situation that they were in, and recreate it in our browsers, and hopefully be able to work with it, right? So for a testing reason, for a debugging reason, this is actually a really kind of cool idea. And it also makes it very maintainable because modifying an object, sure, immutably, right, which makes it a little bit tricky in JavaScript.

And that being the sole source of truth for your state is really cool. The thing is, you don't just start adjusting that tree in Redux, right, in MOBX, you can, right? The way that you change the tree is that you dispatch actions, right? What is an action, an action is basically saying something happened, right?

They clicked that button, they adjusted that value, we heard back from the API, something along those, a thing has happened, right? And we can kinda look at the current state of the world, and the thing that happened, and figure out what the new state of the world is, right?

So we dispatch some actions and they go out. This is cool to talk about, let's look at some very scientific illustrations, that was sarcasm. The kind of main thing in Redux, this is why I bought an iPad Pro. And the main thing in Redux is that you have this thing called a reducer function, right, and you're like, this sounds complicated.

A reducer function is shockingly simple when we look at it in isolation. It's a pure function, right, like we talked about earlier, and it takes exactly two arguments. It takes the current state of the world, right, it takes, again, that giant object, right? Or we'll see that there's a trick for breaking it into smaller reducers and smaller pieces of that giant object.

But it takes that giant object which is the entire state of your UI. And it takes, and something comes out the other end, which is the new state. Now, if nothing happened, you're gonna get the same state of your object. But it takes the entire state of your UI, some action, something that has happened, right?

And it goes, well, here's the state of the world, here's some information about what happened. And basically, you write the logic on what the new state of the world is, right? Once we have that in place, right, our React app can listen for that new state of the world, which is effectively a bunch of props.

Do all of its React virtual DOM black magic that it does, right, and spit a new UI. At that point, we know that in React, we can do an on-click event, or something, other events can happen. Things happen which create an action which go back into the reducer function with the current state of the world, and the whole cycle repeats, right?

As a user modifies the application, we say everything that he does is an action. We take whatever the last state of the world was, whatever that new action is. We spit out a new state of the world, that re-renders our React app, which adjusts the DOM, everything goes really well.

We're effectively separating all of our state management outside of the React application, and just treating it as a giant JavaScript object that we're using with pure functions. There's one more concept that is totally optional, and it's this idea of action creators. An action could just be a string or a number, right?

Likely, your application's complicated enough that that's not feasible, right? You wanna have some metadata like, what kind of action, what was the value, right, what got back from the API, something along those lines. You could theoretically, that action is just an object, and you could type all those objects out by hand.

It will totally work, you can skip the whole action creator part if you really want to, it's totally theoretically kind of fine. What the action creator functions do, you're making functions that will spit out the action object consistently. So that you didn't make a typo, and now you're throwing console logs everywhere, trying to guess, [LAUGH] why didn't it trigger, right?

Cuz you mistyped the action type, or you mistyped the word type, something along those lines. So basically, you didn't flub, the functions help you, right? If you flub the name of a function, right, your application will break, which is good sometimes. Sometimes it's bad, but sometimes a big red pile of errors in the console that tell you exactly where things went wrong is like a glass of water, right, like.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now