React Performance

Normalizing State

Steve Kinney

Steve Kinney

React Performance

Check out a free preview of the full React Performance course

The "Normalizing State" Lesson is part of the full, React Performance course featured in this preview video. Here's what you'd learn in this lesson:

Steve discusses the potential performance benefits of normalizing an application's state.


Transcript from the "Normalizing State" Lesson

>> The other thing that you can also do is just have a layer when you take an API request take. Okay, this was the request but let me then transform this thing immediately before it gets to my view layer of how do I want this actually to be structured?

And like one of the opinions that it will offer. That is, I think, pretty standard, is this idea of normalizing your state. Right, which means, regardless of what the API that you get is, right. Thinking about what the structure should be. And we won't go all the way through this because it's more of an exercise of data manipulation.

And you could write some unit tests, you can make it work. I do wanna introduce the concept though, and talk about it and also answer any questions about because I think it is important. This is what we had, right? I showed it to you in the browser a second ago.

Deeply nested data structures that cause us to break our own performance optimizations just to manage our own data. And like one of the questions Alex brought up in the very beginning was like. Hey, if I don't get keys, should I put unique keys on things on the way in?

And we're like, yeah, yeah, you should do that. And I would say, yes and right, you should do that. And there is more to this at this point, right? Like a more normalized data structure. This is part of I have a file, I don't know why I'm showing you this.

I literally have the files open on my computer. But one of the things I really like about this is, let's actually pull it up. [LAUGH] Turn off the slide, that's my editor now. I have a normalized version we could play around with, it's an exercise, which is for everything.

So for users, I have an array of all the ideas. Right, and this is just, if you took the array of users and mapped it to just pulling out the ID, you'd end up with this. And then taking all the individual users and having an object, right? So now if I wanna show a list of users, instead of taking an array of users, right, I just have all their different IDs.

And I have this JavaScript object that I can key in on any given key on that object and get that value. And what's really cool is, let's say that list that is just getting in this case their fake ID, so one through ten. But imagine they're IDs or something like that.

Let's say we edit an item name. If the list is just saying, I know about item one, two, three and four. I'm just taking item ID. Next time it renders, even if it's a brand new item. All the name has changed and all those things like brand new item and memory.

It's like, I just know that I'm supposed to be playing item nine. In the same way keys work in React, right? And so it's like then you have the actual item that will just go into that object. And grab item 9 directly and doesn't care which other ones got removed.

You're separating the order and sorting and which ones are on the list from the actual pulling of that data.
>> There's actually a library that does this for Redux.
>> Yeah, there's one called normalizer. It's like, you can tell. It's usable and works it's currently archived, it's not taking anything.

I was gonna jump to because it's normalizer without an E in the end like the internet 10 years ago. He has a library that will kinda do this, it's also relatively simple to do yourself, right and I think either one works. But it would create a data structure where you can just swap out one and then you get the comments ideas and you keep those separate.

So if they change everyone is just kind of keying into that object and has all these things. And the lists don't care because they're just looking at the ideas. And you begin to separate this idea out of how you store these things. So you're like you've done all this work to only rerender if an object is changed in memory.

And then confirming that you're not actually doing it when it hasn't. To then change every object in memory all the time for any reason whatsoever, right? And again, because those optimizations, those memorizations weren't free. You've either done nothing or made the problem worse, right. And that's why the thinking about it looking at the tools.

Starting to investigate one you might find things that surprise you. You might understand that there's a fundamental problem which is all the technologies working as expected. What you expect it is not or yeah what is expected is not what you wanted. And those are two fundamentally different things.

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