All language subtitles for 021 Using useReducer() for the Http State_en

Now, here, I added use reducer instead of use state, not because we replaced so many state things

with it, actually we only replace this one user ingredients state, but because we have multiple ways

of changing that state and some of these ways depend on the previous state.

And whilst the previous approach did, of course, all that worked fine using a producer oftenest cleaner

because you have all your updating logic in one place in the producer, and then you just dispatch these

actions, which is a very clear and easy to understand flow for how you manage your data.

So whenever you have more complex states that can change in different ways instead of just, let's say,

setting a boolean from true to false, but like here where we can add ingredients or remove ingredients,

whenever you have such a state that is a bit more complex and that might also depend on previous state,

then you should strongly consider using a producer to have a cleaner logic to have all in one place,

basically.

And ultimately, it's of course, up to your personal preference, though.

Another scenario where using use reducer could make sense, as if you have multiple connected states

like here is loading an error.

They're both related to ascending HTTP requests, and whilst we managed them independently, they're

kind of related.

Now you can of course, manage it like this, but also here often a her makes her code easier to reason

about, easier to understand.

So I'll add an average user again outside of my component.

Doesn't have to be all it said.

You could move it in there, for example, if you use props and your reducer, but if you don't need

to put it outside of the component to avoid unnecessary recreations of the user.

So here I'll named is H to the P to reduce her, maybe again get my HTP state and my action.

And just as before, you can name these arguments whatever you want, of course.

But this will be your old state basically, and that's the action you're getting.

And just as before, we can switch the action type because there will be different actions, we'll dispatch.

And now let's think about which actions might we have when we work with TDP requests.

Well, if we have a look at our code, then we always start by sending the request right, we start

off by sending a request.

So sending a request probably is one action.

And action we then have is when the response is there and then case or when we have an error in this

case, so we have three possible states here that makes sense.

Three different cases, I should say.

So the first case is send or send request or whatever you want to name it.

I'll just name it.

Send.

The second case is response.

So the response is there again, you can name does whatever you want and an error case and justice before

a default case where I however, will only throw a new error should not be reached because we're the

ones dispatching these actions.

We should, of course, make sure we only dispatch actions with these identifiers.

If we ever see the error, then we dispatched some action we're not handling and then we should ever

fix a typo.

We have or add a case for that action.

Now, what happens if we send the request now, it's important to understand that here will not send

the request itself.

We're doing that down there.

I just want to manage to state that is related to that request being sent that influences our UI.

So the state there is basically where we show a loading spinner or whether we show an error.

That's essentially the state I want to manage related to that request.

So here, when we initialize this with use reducer and we point at our DP reducer, then the initial

state could be an object where we have two fields and that is loading, which is falls initially and

error, which is null initially here I'm using an object because I reducers could also just manage a

single string.

But here I want to have multiple connected fields and therefore I have an object connectome.

Now when we send a request, we want to set loading to true and the error probably to null because we

have no error yet.

If we just sent the request and desist, new state will return.

Of course, it should match the signature of our general state like the initial state we're managing

here.

And that is the case here.

We have a loading property and we have an error property.

If we got a response, then all said loading to Falls and al-Said set error to null.

Or actually I just don't want to change the error.

A common pattern dhafer for is that you actually set the property you want to set, but before you do

that you simply take your existing state and use to spread operator to pull all key value pairs out

of it.

Merged with this new object which will be returned as your new state so that you don't lose anything

from the old state and whatever you set thereafter will overwrite any properties of the same name that

were pulled out of the old state.

So if the old state we have a loading property in there, we're pulling that out and adding it to the

object.

But since we all to define it here, we then overrides that value with the new value of our properties,

which we don't override here, will simply be kept in this new object.

If we have an error, then I want to set loading to false because we're still not loading anymore,

even if we have an error and set the error to action error.

So we probably should get it here or error data.

Whenever you want to have here, you're the one writing the code.

You can define what you expect on your actions here.

I'm not using to spread trickery, to spread approach, because here I'm setting both properties, which

my state here has.

So no need to spread existing properties.

I would overwrite all of them anyways.

So that's the age reducer.

The producer use Reducer Dafa returns our H to the P state or whatever you want to name it.

I'll name it if you state it's the same name as I have up there.

So to avoid confusion, you don't have to change any of the two because they're in different scopes.

But to avoid confusion, all named is priv htp or cur htp state because it's occurred in state before

the update up there and here it's just htp state.

And again we get dispatch.

Now I already have a dispatch variable though, so I'll renamed this to dispatch H to the AP so that

we have no name clash here and here.

We need to rename it because they're in the same scope, hence we can't use the same name twice.

So now we can get rid of these to use state statements and now fix all these errors we're getting,

for example, here for loading, in the end, what's happening here is that I want to dispatch an HDP

action and that action is of type send.

So that's the identifier I define here.

And that will then automatically set these state values.

We don't need to pass any extra data to that action because that action doesn't need any external data

to work.

So we send a request here.

Now, when we got a response, I'll sent the response request here, down there in removing Agent Handler.

Again, it's send the request, which I'm sending.

And then here, if we got a response, it's the response request only here if we have an error, well,

then I want to dispatch my error action.

And that's the only action here that that then takes an extra argument, because in our review, sir,

we're accessing error data on the action to get the error.

Actually, I'll rename this, too, error message, because I want to get the message and stored that

an error, so that error always is a message.

And then down there I pass error message as a key, and that is error message or again, a message of

your choice, like something went wrong.

Now in clear error there, we actually need to dispatch an action we don't have yet, so let's register

a new case and that is clear maybe where I return.

My old heard his state, but I said error to null, because that's what we're doing here.

We're keeping all the old state in this new state object, returning the resetting error to null.

So now we can dispatched as clear action here.

So dispatch HTP with an object where the type is set to clear so that this clearing is happening well.

And then here, instead of error, we access HTP state.

Remember that HTP state is now what we're extracting from the result of use reducer here.

So that is in the enties object with loading an error, which we're constantly updating.

So we got our HTP state, which might contain an error.

HTP state error is what I output here and HTP state error, all those what we need to check here.

And then here it's HTP state loading.

With that, if we save this -- again, we're correct me if I add.

A new item here, you see the spinners floating works, we see that here and now if we add an error

again.

For removing, let's say, by again removing that is from Jason Vonow.

Now click here.

We see that.

We see the error model.

We can close it.

So that is now all working.

Let me repeat.

Yes, with that.

We're using a reducer for this to here.

We're doing it because we have multiple connected pieces of state, which we now can manage in one place

and still make sure that we always get the old state, that we update everything correctly, and that,

again, we take some logic out of our component here and move it into the reducer functions so that

we have cleaner code where we have a clearly defined flow of of data and of where we change our data.

Now, we can also get rid of the.

State import here in the ingredients chestful because now we're managing all our state with use reducer,

which is an alternative to use state.

If you got more complex state states that relies on the old state or if multiple state values work together

and you want, you will manage them in one place and update them correctly.