React Performance

Separating Context & State Exercise

Steve Kinney

Steve Kinney

React Performance

Check out a free preview of the full React Performance course

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

Students are instructed to look through the provided repo for performance issues other than the previously solved context issue. Steve then walks through possible solutions to the found performance issues.


Transcript from the "Separating Context & State Exercise" Lesson

>> Your job for about five minutes is to kind of ghost the lunking. There are a few of these little ones in here because as of that grew in complexity, there are a few like, when I found a bunch of them, I was like, great, yeah, totally. But there are a few of them and see what interesting ones that we can find and lead us to work cuz I think it's very simple app's fine, it's cool, cool.

As it starts to grow, and again, we wanna use the tools. What are some of the optimizations? And some of them, we can talk about some of them we can do, right? Cuz some of them just like, as soon as we understand the philosophical thing, I think we've got the major point, but I want you to spend a few minutes, five minutes, go looking for them, right?

And let's talk about some of the ones that come up. I'm gonna look at the chat in the room and we can kind of figure out which ones what some are thoughts and theories around them and what we would do about them. All right, so there are three or four, some of them planted.

I will talk about the accidental one. I will talk about the main one that leads me to my next point, but I'll do that, especially when it leads me to the next point. Feels appropriate to do towards the end. Did anyone else find any interesting ones as they went in triage?

>> I mean standard ones. I've added three memos regarding comments or play around with them. But so I'm around that common common and post it solves a bunch of renders.
>> Yeah, I want to talk particularly about the post comments, and a little bit as well. But yeah, those as well.

And I think in the drop down with the users was pulling the users it's nested in there ,like that one probably can get its own state and be completely isolated from everything else, right? With just a callback, like we saw before we just say, yo, when this changes, let me know but other than that I don't.

This thing is it's got its own context in there, right? To point out so, we know that we have posted we have users, right? And so to Alex's point, in the post, right, we have, instead of add comment, we grabbed the entire list of users, right? And so, someone left a console log in their code, to figure out what the selected user was theoretically, that could be encapsulated on its own and not necessarily need to involve stuff in here as well.

That's a big one. Do we have any other interesting ones, I'll tell you the one that actually I didn't expect and had to squint, right? So I kind of alluded to before we started this I'm like, I shouldn't get into this part yet. I should let you explore first, but any other interesting ones, throughout.

Okay, yeah, well, we'll call it the obvious one which is the core set of data structures is problematic, right? And where I wanna lead with this is, we talked about component hierarchy, we need to talk about the state hierarchy as well, right? And there's just some things and all the memos and contexts in the world aren't gonna save you from.

And we'll kind of do the high level cuz a lot of it is the conceptual understanding, the actual tedious part of doing the work is moving stuff from one place to the other. Which is somebody who originally planned to do that in front of you did it with a test audience and it was like watching paint dry.

So we will talk about it a little bit. But I wanna talk about the one that slightly surprised me and I think I fixed in this branch. So we're gonna see how angry the development server gets if I keep switching get branches with different code over and over again on it and see how it likes that, but we'll find out.

So if we look. If I go ahead and I'll clear this out I'll record was moving to user and maybe it was adding, I forgot. We got a bunch in here though. Let's see which one, I just recreated it to. I will show you in a moment, if I can't figure out exactly how I recreated it or if I'm on the branch that has effects we'll find out.

Don't embarrass me right now. So what I got was, make sure I'm on the right. Don't save anything, go back to the way everything was.
>> There was one weird one with children.
>> Yeah, that's the one I'm looking for. Do you remember how we got that one?

>> I'm on a live coding branch and I've added memos to, To users, not the user itself.
>> Yeah, yeah, that's exactly the one that I'm looking for. Now, I can't recreate it but I can show you what the issue was. So yeah, Alex, can at least back me up that as well.

Which is we're like, go children that's great we should do that, right? And this is again why we test these things because what is super interesting is thinking about, so it's like, it takes the child component and we map in the button, I believe, yeah. Hold on, is this the one that's fixed?

Is that why it's not working?
>> Yeah, [INAUDIBLE] because I have a different version.
>> All I get jumping around.
>> It's in the user, it's supposed to be in user JSX.
>> Yeah, this might actually work on one hand. Okay, yeah, we can actually see the diff but let's let's go recreate the problems, I can verify as you all believe me.

Turns out, switching git branches repeatedly back and forth to try to get ready make a point doesn't always serve you. So let's go check it out.
>> Tony I believe.
>> Okay.
>> Well you're a mobile user.
>> Yeah they all changed individually, thinking about when you go about an item, an individual item didn't change when we removed another individual item, right?

All the rest of them were like, I'm the same thing in memory, it's cool, right? And yet, we get this issue right here, props changed children, right? And we're like, yo, I thought the whole thing when we're gonna pull content up and we're gonna have the children, is that it's all gonna work, right?

And yes, but again, rules apply and things exist for reasons, right? So the reason why that works is because when something happens in the lower component when we saw it with the stupid game, right? The problematic component was slotted in in between parts of the game, but it lived up in application, right?

And so cool, it was the same component React's like, I know you, you're not even on my path, nothing, right? Nothing has changed, it never trigger the change the application to start at that subtree. Never even went up and looked. The interesting part is here, these children are delineated by the array of users, right?

And so before that was just a component that existed that I put in here. When we remove a user, what are we doing to the array of users?
>> It's a new every time.
>> We're throwing out the array of users, which means we threw out this array of children and replaced it.

So any performance optimization that we thought we were getting to make a point didn't work because yes, they are children, but that is a set of children that are based on an array that is changing. Which causes them to get thrown out, right? And so, it's why sometimes, just following, it's like even for all the ones that I hid, that's not one that I hid.

All right that was one that was like ,that's weird as I was like, you hide the Easter eggs and you check on them before the kid wakes up, right? I'm like, that's a that's a super interesting one because I was just, again, I was just going about my business whipping up an example app.

Tried to make a few different points and didn't expect that one, right? And then I had to squint a few days ago and look at it and be like, yeah, that's interesting, right? Because it seemed innocuous, it seemed like it was just the thing, that's what I wasn't even thinking about.

I'm gonna pull this up cuz it's more performing, I was just like, this seems easier right on. But understanding that, yeah, it's really a game about how JavaScript cheats objects in memory and some of the things with immutable state and what that means. The fact that we keep everything mutable is not a first class citizen in JavaScript, there aren't immutable data structures.

We do these things now almost out of habit where we spread operators and stuff like that. But sometimes, you will be surprised even as you just think you're just doing the thing that this, yeah, this is using the children. But because the act of doing this does cause a brand new in that higher level.

You could also see this then if I did that to stop a cascade down a bunch of other components I've accidentally retriggered the entire cascade, right? There's, again, this app isn't big enough to do all of that. But those subtle little things, if you're not kind of getting in the habit of taking a look every once in a while and as you're implementing stuff.

You should not over rotate on performance all the time at the absence of getting anything done, right? But as you're coding, you should develop the habit of the same way you go, what happens if I put an emoji in this input field, right? On the unhappy path of being like, does this perform?

This is doing what I expected to do because that cause a rerender, could have got the bug, right? What if I never expected those components to mount and unmount? What if they did something theoretically like, they had to use a fact that was hooked up to a web socket or something like that.

All sorts of different things that weren't totally expecting, these same principles about how React work. Yes, totally more performing apps, absolutely, here for it. But at the same time, they are also like, okay, this is how the underlying fundamentals actually work and this is what they're doing for us.

Hopefully, if tuples and the immutable record objects come out, we should get better primitives for this. Yes, there was still be, again, we are left with the hard, squishy parts of programming. And so things constantly keep getting better, especially in the JavaScript ecosystem, but building the muscle memory and habit of just occasionally checking in on these things.

And seeing it, I think does create really useful and allows him to insights to write, again, in a larger app over time. This might not have even been a performance issue as much as it might have had weird unexpected side effects, right? So I think that these things go hand in hand and the act of doing this also gives you a deeper depth into what React is doing and why.

Didn't even occur to me until I was here with this thing a week ago. And so that's super interesting. The other one that we saw, there's a lot going on, most of the meat lives in the post comment thing right? The data which both is not great and also not totally shocking from other things that I've seen is somewhat common.

Which is a collection is an array right on. It has the user kind of baked in, which is weird because I have a different list of users, right? So what happens if I do need to change the user's name? Now I have two places to do it, right?

It's tricky because sometimes that is a good choice. And sometimes it's not but it's been thinking of these things. But the interesting part is the act of removing a comment also like rerendered an entire post, right? And there's no number of memos in the world that are gonna save me from that one, right?

And this is one of those things which is, we have a tendency because our UIs are these tree-like structures. That our data structure should be a tree-like structure, right? But if you've ever, especially, in a Redux like thing or reducer like thing where you're like, okay, I need to change something.

Three things deep in a data structure is like spread operator, spread operator spread operator, right, to get to that bottom thing and you have to rebuild everything all the way up. Yeah this is working with immutable data structures, but if your memory lane on something having the same reference in memory, then what are you doing to that memo, right?

You are actively recreating, if you wanted to change the user name on this comment, cool, you immutably spread out and replace that entire object. And you can see these actually have comments built in too, right? This goes, it gets a little insane on purpose. Then you'd have to, they're the comments array, that's, yeah, separate in there.

You get the user, you'd have to then rebuild the comments, you'd have to rebuild the post. So you end up in your data structure, React aside, the simple act of changing your immutable data structure is triggering all these re-renders regardless of what you do, right? And so, I think the two things I definitely just wanna, and one I've said repeatedly, but why not?

Is that the component hierarchy can sometimes matter more than the tools that are meant for helping with performance, but also the structure of your state, right? Actually in the beginning of a project, right, sitting down and think about regardless of what you get from the API, think about what is the structure of the state that I need for this application.

And what do I need to do early on. Cuz sometimes once it's wired in there, the weight of the refactor becomes untenable, right? And so, again, sometimes we don't get to make these decisions over there. It's usually a new future somewhere we can decide to do this of thinking about how are we gonna orchestrate this?

And yes, as a front end engineer who's been doing this for a while, I have the deepest empathy for we all don't get the APIs that we want, right? We fight the battle with the APIs that we have, not with the APIs that we want. I have had to do dark things like stitch together seven different APIs.

I once said, somebody asked me, what does a front end architect do? My joke was how you like to break stuff into tiny little microservices that don't know anything about each other? He's like, yeah. I'm like, my job is to hide that from our customers and make sure they never know that you did that.

Right, but there are things to think about. And so one of the patterns that I really like that is more of a kind of state management data structure pattern, but I think has immeasurable benefits on your React application. Is having a layer that even if you have a back end for front end Great.

Good luck now being on call for a service.

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