All language subtitles for 023 Performance Optimizations with useMemo()_en

Now, if you had a look at so many different hooks, let's take a step back or actually stay in the

Hooke's world, but see how we can optimize our project, how we can avoid unnecessary rewriter cycles,

because that's, of course, something we might all be interested in doing to ensure that we have an

app that performs well.

For that, let's have a look at the ingredients.

Jaspal, there.

We're managing a bunch of logic.

We have to reducers in there.

We're changing the loading state, for example, and we update the UI in this case.

And one thing I can already see there is that, for example, I'm passing the add ingredient handler

to the ingredient form and add ingredient handler in the end is just function.

This means that since it's a function defined inside of this functional component, whenever a dysfunctional

component rebuilds and effort is whole function gets executed again, dysfunction will be recreated.

As a side note here, by the way, use producer and so on will not be recreated.

Of course, this is called again, but react.

The text at this reducer is already initialized for this component and uses that already initialized

value.

So that's no problem.

But here for add ingredient Hanlon's on, we're creating a brand new function.

This brand new function is still for passed down to the ingredient form and hence in the ingredient

form.

Even though I'm using Memmo dismal, rebuilt and I can prove this to you can throw in a console rendering

ingredient form.

And theoretically that should only be rendered whenever we type in there because these are the only

things that change the form.

And of course, when we initially loaded.

But what you will see is that, for example, if I if I add something, test five, let's clear the

lock it add ingredient.

You see it's rearranged a bunch and that makes sense because it's re rendered when we change the loading

state.

Well actually that makes sense because we're outputting the loading indicator here.

But it's also rendered once the data is the area where our putting the data down there and this is not

what we want, there is no reason to render this forum if we're just outputting some data down there.

So that should be one renderer cycle.

Too much.

We have here to make sense because we switch loading from faults to true and then back from true to

false ones.

We're done.

So we definitely will render twice because the loading spinner is in the form.

But the third output here makes no sense.

We can get rid of debt by wrapping.

Adding Raegan handler with use callback, which we already saw before, and for that you need to import

use callback from react of course.

And then you wrap your entire handler function with that.

And then you add square brackets where you defined the dependencies of this function, the dependency

dispatch HTP, which you don't need to specify because just like the updated function from use state

does is guaranteed by react to not change between render cycles.

So you could added, but you don't have to ingredient is a local argument.

We're getting into function, not an external one.

So nothing we need to do there.

Therefore, overall, there's nothing in here on which this would depend.

So this function actually should never be rebuilt.

It's always the same function.

It has no external dependencies other than dispatch HTP, which, as I said, is managed by react such

that it won't change.

So it's not really a dependency.

If we do that.

Then if we log in here.

And I add another ingredient here.

We only see two render cycles, the third one is gone because dysfunction add ingredient handler is

now not rebuilt.

We're passing this function into ingredient form.

But since it doesn't change between render cycles react, Memmo detects that the new function are getting

when the parent component rebuilds is the old function and therefore doesn't rebuild this component.

That's how it works.

Loading when it changes, of course, breaks through that as it should, and triggers a rebuild on the

ingredient form if it changes, if loading would not change, if we had faults before and faults for

the next render cycle as well, this would not be rebuilt.

So now we're taking advantage of react Memmo here.

The same for the ingredient list.

When we change the ingredients, this should rebuilt, but it will now all the rebuild all the time

because we pass in the remove ingredient handler and that's all not wrapped by use callback.

The result of that is that the ingredient list will always rebuild too often if we add a Corn Solok

statement in there.

Rendering ingredient list, something like this.

Then you'll see, of course, loads initially a couple of times because of the loading stage change

it loads initially and then loads once the data's there, but you will all to see that all those in

cases where it shouldn't.

For example, if you click on Test here, it renders way too often.

Of course, it should render once the data is gone, but it should not render just because we're showing

a loading spinner up there.

And that is the first thing we're doing.

So same logic as before.

The dependencies of ingredient list are on remove item.

Please note, I'm not using Rick Memmo here.

So the following change will not alone have a result.

But still it's a first step.

Remove ingredient handler.

We use use callback here and wrap it, wrap this entire function with it and then specify the dependencies.

Dependencies are dispatch HTP, which as mentioned, doesn't have to be specified.

Ingredient ID is an internal value, not an external one.

Nothing else in there which matters.

So it's an empty array.

Now, again, as mentioned, this alone won't make a difference.

If I delete test here, we still see a bunch of ingredient lists re renderings.

Now, it makes sense because an ingredient list I'm not using REAC memo, so of course, we can do this.

We can use react memo here, wrap this entire component with it like this.

And if we do so, we log in, cleared this and I click bananas.

We only render it once.

So we're having the effect we want.

We're only rendering this when this changes, not when something totally different changes.

And there's nothing wrong with doing this.

And actually does this new approach you'll typically use.

Still, I want to show you an alternative, because there always is a never hook you can use.

And that's the use memo.

Hook use callback was a hook to save a function that doesn't change so that no new function is generated.

Use, Memmo, is a hook where you can save a value which has saved so that the value isn't recreated.

And that is a no way of memorizing component.

So here that would be our ingredient list.

Let me cut it from there and add it here.

Ingredient list, maybe like this.

And now I use you as Memmo here, pass a function to it, this is not a function that's now memorized,

though.

Instead it's a function that react will execute for you and that function should return to value, which

you want to memorize.

Ingredient list here.

Now use Memmo also needs a second argument, which is a list of dependencies you have dishtowels react

when it should rerun this function to create a new object that it should memorize.

And we know it should rerun this function whenever the user ingredients change.

So let's add this here or whenever removing Creedon handler changes.

And that shouldn't change because we wrapped that with use callback.

So only changes to user ingredients are really rerun dysfunction and rebuild a new ingredient list.

And now ingredient list is, of course, something we can output.

Down there, ingredient lists like this, we save this and we log in.

Ingredients are getting rendered now let's add bananas here.

Ten.

ATIS, we updated the ingredient list once, if I delete them, we updated it once, it's an alternative

to react memo.

Now if we're talking about storing components, you typically want to use react memo instead of use

memo.

But keep in mind that we use memo.

You can store any data which you don't want to recreate on every Virender cycle of this component.

So if you have some operation that calculates a more complex value, calculates a value which maybe

takes a bit longer to calculate than you want to consider wrapping it with use memo so that it's not

recalculated whenever the component renders, but really only recalculated when you need to recalculated.

That's the idea here.

Now, last optimization I want to apply is here on the error model.

On close we call clear error dysfunction.

And there again we can use use callback to make sure that the error model isn't be rendered unnecessarily.

We have no external dependencies here, so it's as simple as that.

And now we also make sure that the error model which already uses react memo isn't re rendered in cases

where it shouldn't.

So these are some optimizations you can apply and you should think about now.

It's not the end of the world if you forget one, because re rendering sounds like a super intensive

work.

If it's a small component, the easy update might be super fast.

To render and render always means re rendered in the virtual dom.

Right.

You learned that earlier and of course does not mean that whatever change is automatically written to

the real dom.

But even that virtual dom re rendering can be avoided with use called they use Memmo and react Memmo.

But if you have very trivial components, it might even be worth not adding Riak memo.

So you shouldn't wrap every component with Riak memo with use memo because reaction always needs to

check whatever props changed.

And if it's a super small component re rendering, it might just be faster than performing that check.

So it's always something you have to evaluate and think about.

For example, for the error model we could probably get away with always re rendering that and not using

react memo.

So these are examples and these are things you just have to play around with test and also check how

fast your application is to get a feeling for this where it makes sense and where it doesn't make sense.