to compute. Now obviously it doesn't, all it's doing is using reduce to add up the numbers in an array. But to simulate slowness, I have this for loop, which iterates two billion times. And you can really feel it in the browser when you try to update the state. We also have this changeArray method, which updates the array. And down here in our JSX, we have our counter. And we have the expensive computation happening here. So we're calling addNumbers. So before I uncomment this, let me open up DevTools here. Let me refresh. And you can see every time we update the count, it has to run the addNumbers method again. And as you see, it says I take long to compute. So let me add the slowness here. So I'm going to save this. And now if I reload, you'll see that it takes about a second. And as I update the count, it does take about a second for the count to update in the browser. So why do we have to compute the result of this method, even if we already did.

it takes about a second. And as I update the count, it does take about a second for the count to update in the browser. So why do we have to compute the result of this method, even if we already did it once. So that's where we can use the useMemo hook to cache the result of that method. So if it's in the cache, make use of it. But if it's not, or if the inputs change, then we do have to run that method. So it's pretty straightforward. We can make a new variable here. Let's say memoizedAddNumbers. And we can use the useMemo hook to memoize the result of addNumbers. So useMemo. The first argument is the method we want to memoize. So it's addNumbers. And this memoizes the result of this method. Okay. And the second argument is a dependency list that tells us when we want to recompute this method. So in this case, we want to recompute when the array changes. Okay. And let's make sure to import useMemo from React. Okay, that should have imported up here,

obviously, this has to recompute, because the array is changing. So it has to sum up this new array, which should be 10. And that should take about a second to complete. You see an update here, and you do see I take long to compute here. But now as we update the count, it should make use of that cached value. And it does. Cool. So yeah, that's basically it for useMemo. If you have a method that takes long to compute, consider memoizing the result using the useMemo hook. Next, let's take a look at react.memo, which memoizes entire components. So I have an app prepared here, let me just rename this one to app useMemo. And then I have this other one called app other, which will be our starting point. So let me rename this to app. Okay, let's make sure that rendered in the browser. And it looks like it did. Let's go through the code here. So app is the parent component, you can see that

point. So let me rename this to app. Okay, let's make sure that app is rendered in the browser. And it looks like it did. Let's go through the code here. So app is the parent component, you can see that on console logging parent is rendering every time it renders, we have two pieces of state here, we have a count that starts at zero, and we have another count that starts at 100. We have incrementors for those two counts. And in our JSX, we have the counter here, we have another count here. And then we have a child component, which is rendering here. And that is here. We also have a console log every time the child renders. And we also have a grandchild here, which is basically the same thing. So by default, the way React handles re-renders for children is that anytime the state changes on the parent, the child will re-render as well. So let's take a look at this. Anytime the state on the parent, so anytime any of these counters

is highly optimized to handle re renders. But as your application grows, you might want to take this into consideration. Now, like I said, when any props that are passed into the child changes, then the child has to re render. So let's go ahead and do that. How about we pass in the count to our child here. So it's a count equals count. Okay, let's grab that in the child. So in here, we can destructure it, say count, and let's just output it here. Okay, let's say count. And let's save that. So now back to our app, let's refresh. If I change the count here, then the child has to re render. And it does. However, if I increment the other counter here, which has nothing to do with the child, then the child should not re render. And it doesn't cool. Again, if we were to remove the memoization on the child, then even if I update this,

it by two by two. Okay. Go ahead and save that. Let's go into our child and accept that prop. So it should be incrementByTwo is being passed in as a method or a function. And let's just make a button down here that triggers that function. Let's say button plusTwo. And on click, we are running that method. So incrementByTwo. Okay, so let's save that. Let's go back to our app. Let's refresh. And if we try that, that should increment by two. And it does. And since the count is changing, the prop does change and the children are re rendered here. However, if we try incrementAnother, which has nothing to do with the child, initially, you might think that the child should not be re rendered in this case. So let me just refresh here. Let's try incrementAnother. And you can see that the child is re rendered here. So what's happening here? Again, this other counter has nothing to do with the

So let me just refresh here. Let's try increment another. And you can see that the child is re rendered here. So what's happening here? Again, this other counter has nothing to do with the child. The props are not being changed. So why is it re rendering? So let's go back to our app. When we increment another, it's updating anotherCount, which has nothing to do with the child here. So why is it re rendering? So when you're passing in props, you have to consider primitive values and non primitive values. So in this case, we're passing in a function, which is a non primitive value, and non primitive values are passed by reference. So as a review, let's take a look at some objects here. Let me just refresh this. Let's say const a = { name: 'Andre' }; Okay. And if you do the same thing, but assign it to another variable here, even though the values are the same, since this is a non primitive value, in this case, it's an object, when we do the

Okay. And if you do the same thing, but assign it to another variable here, even though the values are the same, since this is a non-primitive value, in this case, it's an object, when we do the equality operator, a equals b, then it's going to be false, because these two objects are in different places in memory. Now, if they were primitive values, let's say const c equals 'string Andre', and same for d, then they are passed by value instead, and the equality operator will be true. So what's happening in our application here is every time this parent is re-rendered, this method is being reinitialized. And even though the value is the same, it's in a different spot in memory, and the child thinks that the prop is updated. So this causes a re-render here. So if you want to prevent that and memoize the function, we can make use of the useCallback hook. So it's pretty similar to the useMemo hook.

So this causes a re render here. So if you want to prevent that and memoize the function, we can make use of the useCallback hook. So it's pretty similar to the useMemo hook. So let's say const memoizedIncrementByTwo = useCallback(incrementByTwo, []); Okay, so let's save this, actually copy this. Let's duplicate this. Let's use that new memoizedIncrementByTwo here for the method. And now if we try to update the other state, we should have a memoized version of this function. So the child should not re render. So let's try that out. Let's refresh. Okay. And if we hit increment another, it should use that memoizedIncrementByTwo function and the child should not re render. And it doesn't cool. So yeah, as your application grows, and you start to notice some performance