All language subtitles for 025 Sharing Data Between Custom Hooks & Components_en

So how can we update our ingredients here in the ingredients component when our delete request is done?

Well, again, we can use a hook.

We already learned about use effect.

Remember that use effect runs after every render cycle.

So use HTP sends a request.

And in that request, in the end, we dispatch response.

If we succeed.

This updates the state and therefore it will trigger the component that uses our hook to rebuild itself.

So our component ingredients component will rebuild itself when we send request is done thanks to the

logic we have in our hook, because this patch HTP, which is coming from use reducer updates to state

this rebuilds the component in which it is used.

It's of course using our hook, but that hook is used in this component.

They for this component rebuilds.

By the way, if we would use the same hook in a different component that our component would not rebuild,

because as I said, the logic is copied for every component.

They're not sharing the same data.

So if you're sending a request in Component A, that does not mean that Component B also sends Bernet

or anything like that.

You're just sharing in the sense of copying the same logic across components here.

However, we know that this component will rebuild whenever the request response there.

Hence, we can actually turn this, use a fat call here into a more useful one, we can listen, for

example, to the data because we know that on our accustomed request here, when a response is there,

we opted response data.

And that means that we set data here on our states.

Our data changes when our response is there now for a delete request, we get no data, but still will

change.

Something here will set a new value in response data and that alone should suffice here.

So in ingredients charts, we're listening to data because it this a fact call here.

When we have new data, then I want to call dispatch, which is now coming from my ingredient user here,

dispatch type delete because we deleted a component in the end here.

And pass the ID problem is, where do I get that ID from, I need the ID here on the actually I'm creating.

But this U.S. Faycal knows nothing about the ID.

Well, solution, again, could be that we add a feature to our hook here to our custom hook Indy custom

hook, we can add another field like a request extra, which initially allows is null.

Now, that extra can be sent set when the request is sent there, we can set extra to action extra,

let's say so.

Expect to have an extra field on the incoming action we're dispatching to send request here and there.

We can send an extra a Saturday Extra and I expect to get this from outside.

So as an extra in to send request function, I get my request extra and I'm storing this in my state

here.

So back to our ingredients component.

When we call send request here.

I sent nobody saw a personal here, but for request extra, I forward the ingredient ID, so now it

is ingredient ID gets added to send request in to hook where we define this function.

We then store it in the state, which is the state for this component.

Right.

And therefore.

We can now all the return that request extra here.

In the data by getting it from our HTP state extra, and that means that in the ingredients component.

There we can also extract request extra from the result of use HTP and now use that here in use effect.

So that the.

I.D., I need to provide for the delete action.

Here actually is my request, because we know that we'll store our ID and request extra when we send

that delete request once the delete request is done, once the response is their data will be emitted.

Hence this effect will run and then we can dispatch, just delete action, which adjusts our ingredients.

So here.

Let's add request extra and there should work.

Now, let me also step in here for a second and make it really clear that it can be strange to think

about HTTP requests like this at first, that we're sending them somewhere and we're handling the response

somewhere else in use of fact here.

Nonetheless, this really embraces the concept of hoax, after all.

And what's it can be strange to look at a HTP request like this initially?

It actually makes handling it much more elegant in the long run, I believe, because you can clearly

see in your code where your handling result of your request, where you're changing your data and where

you're just dispatching that request, where you're sending it off so to say with send request nonetheless.

And I want to emphasize this here.

An alternative would have been that the send request function were returning in our use of the hook,

that this send request function, for example, returns the normal promise, the fetch method, the

fetch API always gives us.

So did it in the places where we called send request, we can add a then and a catch block and then

simply still do our logic in these then and cache blocks instead of using use affect this approach here

of splitting the sending of the request and the handling of the response can be more confusing initially

because now you have to care about getting things like that.

Request extra from the I send my request place to the I handle the response place, which is our effect

here.

Nonetheless, in the long run, as I said, I think at least you to write cleaner code where you split

your responsibilities and where you just have to switch to where you think about it, and then you'll

actually have no problems with that approach.

Just be aware that if you're not liking this approach at all, you could return a promise in your HTP

hook instead of send request there and then simply change all your response, handling logic after send

request in this component in this ingredients.

And you could do that.

But using this approach here with you as a fact, handling the response simply is the approach where

you really embrace Hooke's and use them to their fullest potential.

Now, I ran out of ingredients, so in order to test this, let's first fix the add ingredient handler

now.

An add ingredient handler thus far, we're also dispatching a send request and so on, instead, now

we call send request, which again is dysfunction coming from our custom hook here.

So we call send request, do you are l is of course, the same you are we used to down there so I'll

just copy that.

The method here, since we add ingredients will be post the body will be that body we had before needs

to be JSON.

So let's use JSON string of ify and here I need no special extra so I won't pass that.

So this again called send request and justice before this goes to a rook, executes this function amidst

this event and once the response is there amidst is responsive and it stores the response data.

So now, again, we can use our effect to react to that data in the ingredients, Jaspal, and update

our local ingredients based on that data we got back.

So here we have use a fact watch reruns where the data changes were when the request extra changes and

oh, we then always dispatch a delete request.

Now, that's probably not what we want here.

Well, in the end, we can find out what should be dispatched.

We know that if we have a request extra in our application here, we want to dispatch a delete request

because we only use that extra thing for delete requests.

So if we have extra if that's not null, then it's a delete request.

And to make sure that this gets cleared for every new request, I'll go to my custom hook and actually

set extra to null here when we send the request, but instead store it on the response.

They're all set extra to action extra.

And that means that further down in our custom hook, we no longer append the extra when we sent the

request.

So I'll get rid of this year.

Instead, we spent the extra ones, the responses there.

So a tiny tweak here so that in ingredients chest, we know if we have an extra, then we're deleting

or else.

In our case thus far, we're adding so here I can dispatch, well, basically what we did before.

Let me scroll down, can dispatch this here, so let's copy that.

And use it here, remove all the comments now, of course, here I'm relying on some.

Data from the response, the good thing is we're getting that data, so that should be data name because

we're storing whatever response data we're getting in our accustomed hook.

Restoring that, we're sending this here along with our action, and that gets stored in our state there,

so we store response data and data.

So a good thing is we have access to this.

But for the ingredient which we all want, we're missing that.

Now, he could sentence along as I request extra, of course.

But then this check here, your.

Still.

Let's use requests extra here and then worry about this in a second step, so request extra should be

the ingredient which gets added.

So an add ingredient handler where we get that ingredient, which just misstated, I now will forward

that ingredient as an extra.

But now, since we have extras for both deleting and for adding, we need a different way of differentiating

these two facts for handling the two results.

We're getting back from our hook.

Therefore, in the hook I'll add a new field, the last one here to my state, to the initial state.

That's the identifier.

Initially, it's null.

But we sent this where we dispatch to send request, let's say.

Then we set identifier equal to and I expect to get an identifier as an argument, I request identifier

maybe so I'll set this here.

I passed the action and then the reducer when we sent this all set identifier here equal to action dot

identifier.

So now we can append an identifier to every HDP request.

And that's just what I'll do in ingredients.

Jass when we dispatch excuse me, when we sent the request here for adding an ingredient all named as

add ingredient, that identifier here is totally up to you.

You can use any identifier you want, can be a string, can be a number.

I'll use add ingredient as a string for removing an ingredient.

I'll use an identifier of remove ingredient.

And now we can use these identifiers in our effect to clearly identify our logic, so let's.

Gets the identifier from use HTP, let's make sure we return it there so in our custom hook at the bottom

or return everything there.

We should also return to request identifier from HTP State Identifier.

Now, since we're returning it here in a custom hook, we can pull it out of the return value here in

ingredients Jass request identifier like this.

And now with it pulled out, we can add it as a dependency to use effect.

And then here check if request identifier is equal to.

What did I use, remove ingredient that's my identifier here for deleting.

And for adding, I use add ingredient, so here, I'll check else if request identifier is equal to

add ingredient, otherwise will not do anything.

So this should now be all and I know it was a lot that we need to also add ingredients.

So let's log in here.

And let's add a couple of apples here.

And I got an error Keniry property, name of NUL in ingredients, Shabaz, line three.

Do you have any idea what could be causing that?

Well, it happened pretty fast, if you saw that, so the problem is that he was, in fact, runs after

every Renderos cycle.

And when does this component render balladry renders?

For example, when our custom hook here does something, when it dispatches to send action, which actually

sets loading to true, that causes ingredients to render because we're using loading in there.

Makes sense right now since that is case.

We want to make sure that we don't.

Just check the identifier here before we dispatch actions, but we all to check whether we're done with

loading because of reloading, then we might have data, but we're not done loading it.

Yes, data will only be set if a response is there in our custom hook here.

But when we dispatched the first action.

We also see data for the first time, so just watching for data changes alone won't do the trick, especially

since request extra and requests identify all of them might have changed and hence the effect will rerun.

So here we need a more granular check.

We can check if we're not loading anymore.

And of course, that means that we now need to add is loading as a dependency or to use effect.

And we have that identifier here.

And down here for adding it's the same, we're checking for not loading and the identifier as add ingredient.

In addition, I also want to sure as you are here that we got data so that this is not null or that

we have no error.

That's the better check, probably.

So we should all get error here.

All the check that makes sense for deleting, I want to ensure that we have no error here.

So now let's save this log in.

And let's add some bananas here.

And this looks good, this looks way better.

They're getting added, you can see them here, too, and this works in half a delete.

Let's say the apples dissolves is looking pretty decent to me.

It now works with de help for a custom hook.