Lesson Description
The "Wrap a Component with memo()" Lesson is part of the full, React Performance, v2 course featured in this preview video. Here's what you'd learn in this lesson:
Steve introduces the concept of wrapping a function in React.memo to optimize performance. He explains how memoization can be implemented using useCallback to prevent unnecessary re-renders. Steve demonstrates how using useCallback and React.memo can help maintain static values and prevent unnecessary rendering of components.
Transcript from the "Wrap a Component with memo()" Lesson
[00:00:00]
>> Steve Kinney: We could go down the entire rabbit hole, we can do it a little bit more too, right? So we can go ahead and we could then wrap the entire component in React.memo. So you can either pull in all, we can just do memo in this case. Gotta get myself a little space there to pull it in. And we can wrap this function. And all that's doing is it's taking the function, wrapping in another one that's doing that check before calling.
[00:00:41]
We got to go like that. So now we wrap the function in a new one. It's got the same API as far as we are, like it's got some weird types of stuff, but as far as we care, the same stuff goes in each time. Now, again, we probably have some memoization stuff to do here as well, but let's just see if there's any, again, checking every time is a good thing even if nothing changed.
[00:01:04]
Especially if you introduce a bug. Calculation card, because you are talking and you are typing at the same time. Great. All right, so we will go over to the profiler and I'll start from the very beginning. Go ahead, we'll add one in. I don't think we get any changes at this point, but I want to make sure, we've got. It's named two because I got two of them, but it's fine.
[00:01:45]
All right, so we've got that in there. We are down, we lost a millisecond, but I'm not willing to, I'm willing to say that's probably to chance, right, of just, you know, because other stuff going on, so on and so forth, right? And so now, effectively, we can see that those cards are getting called because on update and on delete are also, but we saw how to do that in the last example, right?
[00:02:08]
So we know the trick here as well, which is to go up to at this point like was effectively their application component and we've got this update calculation and delete calculation, right? But like, as far as we are concerned, right, like if, for instance, um, let's see where we pass it into the calculations list. Oh yeah, we pass it on update and on delete. Cool, so let's go ahead and find that and go application.
[00:02:54]
Where's our update calculation? There we go. And really, since these use the, um, this map here, what we can probably do, right, because these are just using the calc and the input for each one. So here we can use a useCallback and do we get, what do we get yelled at for here? So we need to do a little bit of a change here, right? We've got the set calculations that's taking the calculations, but we saw earlier that we can use a function here instead, so we don't have to rely on calculations.
[00:03:50]
We can say, hey, when you call this one, pass in the previous value, right, and then go ahead and return it back out. So we can even change this to previous. Right, and then we'll pass that in. And now I don't have that anymore. Right, so that little change in the syntax from passing a value to using a function means we no longer rely on having to have that value in closure scope anymore.
[00:04:28]
We'll get a copy of it that we'll use. And here we'll do it again and again, we will have to do that same little syntax change here where instead of using the value directly because then we need to make sure we have the same one in memory, we will use that other syntax for giving it a function and letting it pass in. Set calculations previous. And we'll do. Cool, cool, cool.
[00:05:07]
I need to give it an empty array. That's mostly like, undefined does behave differently than an empty array. I think undefined will render every time it's an anti-pattern, you shouldn't do it, so I've forgotten the details, to be honest with you. I was arguing it with my coworker as we were like deeply discussing it, but then like going around in circles. So, um, this case, we're saying like this has no dependencies.
[00:05:30]
So it feels like, oh, I could just admit that undefined does behave differently. So we're going to say this one has no dependencies. And unless I've done the famous move of making a mistake whilst talking, I don't think I did, but you never know. We'll go ahead, we'll refresh this. I'm going to start it fresh. Oh, I got an issue. Update calculation is not defined because these return functions.
[00:06:14]
These can be anonymous technically. At this point, I just need to make sure that I have them as values here. You can name them twice, you can delete them, it doesn't really matter. But we need the return value of useCallback, you can't just float around as a function itself. Great, I'm going to go into the profiler again. I'm going to add a random one, there's a lot less green flashing going on, and now you can see like the list changes, the new one is there, but I am not rendering any of this code anymore, right?
[00:06:51]
Because I said, hey, I want referentially the same, like if, like, nothing because like update and delete don't rely on anything because they're going to take the previous one in their function. So they have no outside dependencies, so they can stay static, just like set calculations or any kind of set state function. And we're also saying that and for any given calculator card, you get the same values, you don't need to re-render, right?
[00:07:22]
If we were to like go ahead and change the value of this one, right? You will see that then this one rendered again, and that useMemo didn't render, didn't work because it got a new number, right? So if anything has changed, but these other ones didn't render at all, right? These like this faded out, it just completely skipped. Nothing happened here, right? And so large swaths of work did not happen at all, right?
[00:07:49]
And again, not doing stuff. And the reason they look so small is because nothing happened. Right, if something happened, they would have been longer, right? But they are small because this is what they, this is what they clocked in as last time, and we didn't do anything.
Learn Straight from the Experts Who Shape the Modern Web
- 250+In-depth Courses
- Industry Leading Experts
- 24Learning Paths
- Live Interactive Workshops