All language subtitles for 011 Optimizing the Custom Hook Store_en

With all of that configured, there's one additional thing we can do, a little optimization we can

put into place now that we have our own management system in the product item, just fall there.

I can add a console lock statement where I say rendering so that we can see whenever diskettes re rendered.

Now, if you go to products, this gets rendered four times because I have four products, let me clear

that and click favorite you see now it is all the rendered four times actually should only render one

time because this item here changed.

We're updating the button look and so on.

So therefore this definitely should be rendered.

That makes sense.

But the above three items shouldn't really be rendered.

They weren't touched.

So to avoid that these items, Virender, you could of course say, yeah, sure, let's wrap them in

react memo.

Right, react memo around these items should make sure they don't re render if they're props.

Didn't change at the props for the other items.

Certainly didn't change.

They have the same title, the same favorite status and so on.

You'll notice if we do that, they still remember the reason for that is our custom hook in each product

item.

I'm using use store, so I use my custom hook and in that custom hook, we use use the state.

So whenever set state is called here, the component that uses this hook will be rendered makes sense.

It's the intended behavior.

It's the default behavior.

Well, we can fix this or improve this in our custom hook here in the U.S. or Hook, we could accept

an argument which is maybe you should listen and we can even assign a default value here.

Let's say true.

Now, we can use that to determine whether we actually want to register a listener for this component

or not.

So for this component, which is using a store, because if we have a component which only uses our

store to dispatch actions like our product item is doing it, well, then we don't want to listen to

changes inside of this product item component.

We're not interested in state changes.

I'm only using the hook so that I can dispatch actions.

So in the store, Jaspal, we can now go to use effect and check if should lessness true and only add

our listener if it is.

And, of course, also only tried to clean it up if we are listening, so only if should listen is true,

only then I'll try to clean that up.

That also means that should listen is now a dependency of use effect.

So we should add their.

Now, this allows us to do the following, we can go to the product item in here and use store, I can

pass and false.

So false is now a value for that should listen argument.

So that means that in product item, I'm not setting up a listener.

So this item here, this component should not register a listener in my global listeners area and therefore

it shouldn't rebuild when our store changes because here I'm really not interested in store changes.

Does store change about this single product, which I set to be a favorite is.

Reaching does Eitam anyways, because dad is something I'm listening to in a product JS file where I

rebuilt this list of products when, well, I mark something as a favorite and therefore this specific

product item will get a new prop anyways that will go through Rick Memmo and therefore this single item

will rebuild, but the other items shouldn't.

So now let's save this and let's test it.

Now we only see one rendering call here.

If I mark this as a favorite and this makes way more sense than the four calls we saw before, because

that only makes sense if we are rendering the entire list for the first time, but certainly not when

we only update one item.

So that's a tiny optimization, which we can also put in place here and which also hopefully shows you

the power of custom hooks and of this custom state management system.

You can really optimize this for your requirements and your needs.