All language subtitles for 009 Adjusting the Custom Hook Logic_en

So we should add fetchTasks

as a dependency here to useEffect

because you'll learn that basically

every piece of data or function,

which is set up inside of a component function,

which you are using in useEffect

should be added as a dependency.

The problem with that

and therefore you shouldn't save this file yet,

is that this would create an infinite look.

Why? Because we will call fetch tasks here

and this will then go ahead

and execute this send request function in the custom hook,

and that will then set some states.

When the states are set

the component where we use the custom hook

will be re-rendered because I explained

that when you use a custom hook, which uses state

and you use that hook in that component

that component will implicitly use that state

set up in the custom hook.

So the state configured in the custom hook

is attached to the component where you use the custom hook.

So if we call set is loading and set error here

in the send request function in the custom hook

this will trigger the app component to be re-evaluated

because I'm using that custom hook here in that component.

Now, dad, however, will then call the custom hook again

when that component is re-evaluated

and when that custom hook is called again,

I am indeed recreating the send request function

and I'm returning a new function object

and therefore useEffect will run again.

And that happens because

as I explained earlier in the course

in the behind the scenes module

functions are objects in JavaScript.

And every time a function is recreated

even if it contains the same logic,

it's a brand new object in memory

and therefore useEffect would treat it as a new value,

even if it's technically the same function

and it would re execute it.

So to avoid this, we should go to useHttp

and wrap sendRequest with use callback

which we can do also when we use a single weight in there

this is no problem.

So we import useCallback

and then wrap this function here with use callback.

Now use callback, also needs of dependency array of though,

and this dependency array

also should list everything which is being used in here.

And in my case, that is for example,

that requestConfig object

but also this applied data function which recalling.

Now this poses yet another problem though,

since that is the case, we should add request conflict

and apply data as dependencies here.

But of course, both again are objects

requestConfig as a standard JavaScript object,

apply data as a function

which you learned also is an object.

So back and the app component

where we're passing in this object and this function.

We again have to ensure that these objects

are not recreated all the time when this function runs again

which they currently would be.

So here in app component, we also should import useCallback

and wrap transform tasks here with useCallback for example,

and add our dependency array here

and here we don't have to add anything

because in here I'm not using anything external

other than set tasks which is a state updating function.

And as explained multiple times in the course,

these are guaranteed to never change.

And if this is looking cumbersome, yep.

it can be tricky to get into,

it might look like a lot of work

but it is something you're getting used to over time

and it is very logical in the end.

It is simply related to how JavaScript works after all.

Now with that we're guaranteeing

that transform tasks will not change all the time,

but this object here will

we are recreating it here all the time.

whenever the app component is re-evaluated.

So to work around that, we could look into use memo

or anything like that

to ensure that this object doesn't change all the time

or we change our accustom hook again.

Instead of accepting the requestConfig here

in the hook itself,

why don't we expect that here in the send request function

after all that is the function

which is being called with that Config.

So we could expect this requestConfig object,

not here in useHttp, but here in send request, so here.

Then we don't need to add it as a dependency here

because it's now a parameter of this wrapped function,

not an external dependency.

And therefore we got rid of this issue

and in app component, all we gotta do is take this object

with the URL and remove it here

so that transform tasks is the only function

we're passing to useHttp.

and we then go to fetchTasks

where we are sending the request in the end,

keep in mind that fetchTasks is just send requests because

of this alias in here and we pass our conflict object here.

That's something we could do.

And of course we could do something similar

with the data transformation function.

If using use call that here in app component

is too cumbersome for you if you don't like this approach.

We can get rid of that

and instead just pass transform tasks

as second argument to fetch tasks here

and not to use Http so that we called useHttp

without any arguments.

And we actually create transform tasks.

Oops, get rid of D dependencies here.

We create transform tasks like this instead of the effect,

then there's all there's no external dependency

in the effect.

And now we make sure that you useHttp

our customer who can be called without any dependencies

or without any parameters,

because we're passing the request specific configuration

and the data transformation

that should be applied after the request was sent

directly to the request.

And I showed both alternatives

because both would be viable ways of doing it.

And I also wanted to show you what the potential downfalls

or disadvantages of the other approach are.

Now, of course, we need to go to use Http

and not expect apply data here

as a parameter off the custom hook

but instead here for send request.

And with that of course, useCallback here

in our custom hook has no dependencies anymore

because all the data it's operating on

is received as parameters in the rapt functions.

We've got no external dependencies here.

And with all of that, if we go back to app.js

we now have code that should run without an infinite loop

and without any issues.

If we now go back and reload,

the tasks are still being fetched.

And again, I'm fully aware

of the fact that this can be confusing.

I hope I could still explain

why the different steps were needed.

Of course I could have shown you that final solution

right from the start,

but it is super important to understand

that there are different ways of achieving this

and the other solution wasn't bad or wrong.

This is just as solution

which minimizes the number of dependencies

makes it a bit easier to manage

but the average solution would have been fine as well.

And most importantly

I wanted to make it clear why we derived this solution now

and why I'm going with this solution now.

With all of that though,

the hook is looking good and app.js works.

But of course, the main reason

for adding the hook in the first place

was to reuse logic across components.

And here in the app component we're fine now

but we still got our new task component

where we also are sending our request.

So let's use our custom hook there as a next step.