State Management with Redux & MobX

Implementing a Kanban Board

Steve Kinney

Steve Kinney

State Management with Redux & MobX

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

The "Implementing a Kanban Board" 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 next course project, creating a Redux implementation of a kanban board. The Normalizr library, which will be used throughout the project, is also introduced.


Transcript from the "Implementing a Kanban Board" Lesson

>> Steve Kinney: So we're gonna implement this application, we're gonna do a kinda simplified version of the Kanban board that we did in the prequel. We're going to, this time do it in Redux. And there'll be no prop generally, cuz we have the ability to keep all of our states very separate and pass it into just the components that we need.

So we're gonna start, there's a branch called Redux-basis, and we will start there.
>> Steve Kinney: Cool, for those of you unfamiliar with the application, if you are, there's a few little changes. We've got the application component, which has the ability to create a list and shows us all of our lists, those will eventually show the cards.

We've got our users, right now this is a completely, there's no concept of state in it, there's also just no state in it, cuz we haven't hooked Redux up yet. So this is the kind of default data of our application, and it's not what we say normalized, like cards.

There's a separate set of cards for every list, which means to change a given card we're gonna have to go through all the list, find the right list, go through all the cards, find the right card, it's a series, it's arrays upon arrays. We also have this ID of users, users have IDs, but then if we wanna assign a card to an user, it might be problematic.

So one of the things that we do at Sungrade is, that we will go ahead and we'll take the data as we get it from the API, and kind of change it. We do this by hand, but there is a great library that we'll use for a second, to just kind of restructure our data in a way that makes sense.

So this is called Normalizr, and it's kinda like the 90s, or not the 90s, my God, it's more like 2010, where everything was taken, so you took the E out, when you had like Tumblr, and Flickr, and stuff along those lines. And this allows you to kind of take some state, so this is the same one I showed you a second ago.

And you can define a schema. And so we look at what we can pull in from Normalizr, you can see that there is a normalize method and the schema object, right? And what this does, you can do this all by hand, we do it by hand. But for our purposes today, just so you don't have to watch me write all this code by hand, we'll actually use a helper library, which I think is great.

There's not a particularly good reason, we actually have it installed in our package JSON with the intent of using it, and then we just wrote them all by hand for reasons. And so, Normalizr itself gives you functions for normalizing and denormalizing data, cuz you might need to change it back to send it to the server.

What we do is, we have an adapter layer where we intercept, basically every Ajax request on the way in, change the data structure to be something that works for our UI, and then when we're sending post-requests back to the server, we will change it back for the way the API likes it.

And for us, just some of the nuances there meant that we had to do it by hand, but we're pretty free at this point. So, you basically can define a bunch of schemas, so here we have an user schema which is just, you're giving it a name, and then you can say, normalize our users.

And if we look at this object, you can see that it took that array of users that we had, where it's just an array, there's these objects in it, and it gave me two things. It gave me this entities object, where I'm getting, just like I was trying to sell you on before, keys, and values.

So now if I need to remove the second one, I don't have to iterate through. Two is not hard, but there's like a thousand, that's a pain. You don't necessarily want to, returning that brand new array will also, theoretically trigger a bunch of rerenders in React, which we don't wanna do if we don't have to.

And it also gives me this array of all of the IDs. This is incredibly useful, that we're gonna use later on which is, instead of, hey, here's an array of all of the users, iterate through them to make your independent user objects. Well, now if an user changes, I don't wanna take that list and have to rerender it, cuz it will be a brand new array.

I can change just that object and the kind of container object that is the users, plural, won't have to change, cuz it's only getting this, and this will be the same array. Yeah, I'm gonna make you a Redux container with the one with the idea of one. We use mapStateToProps to figure out which one number 1 is, in a second we'll figure all of that out, but it gives you basically a more sustainable way to manage your state.

There'll still be some tricks that we have to pull with the, a mutable state that we saw in the very beginning, but it's definitely a nicer way to do this. You can also define relations, so we can say that a card, we can say that our schema for cards, cards exists, but they will be assigned to an user.

And so this will, instead of having the total version of user object, you'll have an assign to property which will point to just that ID, which then we could go to that other user schema and pull out just that user. And then this works the other way too, you can say that a list has an array of cards.

And before, when all of our cards, that each set of cards for a list were nested all together, you'd have a list and its cards, another list and its cards. This makes it hard to define the card that you're trying to remove or move, or something along those lines.

We'll see the kind of data structure that we get in a second, and it will work out a lot better for us. So again, you'll see we have the entities here, where I'm gonna have a collection of cards, and that card will be assigned to one for instance, we'll see the rest of those properties.

The list, on the other hand, no longer have all the information for every card, it just has the IDs, which we can then quickly look up in this object as well. And users is pretty much the same, so it gives us this ability to kind of structure our data, so we're doing quick look ups on an object.

Each one just points to the ID, we don't have to go through all this data structure and figure stuff out. If an user changes its name, the card doesn't care, it's just pointing to the ID that it's assigned to. If a card has to change its description, the list doesn't need to get updated, cuz it's just pointing to the ID.

So, this saves us a bunch of work, it saves a bunch of performance work, everyone is a lot happier in this case. So we can kinda, go through and see everything, let's actually go head and implement this.

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