Original subtitles

Now, in a scenario like this.

We have three different states we're managing and they're all kind of related, if you're honest, they're

all related to us interacting with an HTP request.

Our user ingredients change whenever we send the request because we either load of data or we delete

the data or we add a data.

And we're waiting for this request to be done right before we change user ingredients.

Or we might also have an error.

So these free states are actually closely related.

We're managing them kind of independently.

But all the we sometimes updates to at the same time, like here where we set error and said is loading

right off each other thanks to reacts batching mechanism, that's no problem.

It works just fine.

But still, it might be a bit annoying to manage these states independently.

By the way, that would get worse if one of the states would depend on another state, which arguably

kind of is the case already when we set our ingredients because we added a new one, we're depending

on our old ingredients.

It's not really a different state.

We're not depending on loading or error here, but it's older snapshot of the same state.

So in such cases where you depend on the older state or you need to update new state based on maybe

also some other new state of and never state object, then there is a better way than using use state

you can instead call or use.

Use reducer and no built in hook.

Now, if you follow through the redock section, the word reducer already tells you something.

Reducers are functions that take some input and returns an output in the end and use her to use her.

Use a stat to give you a clearly defined way of defining state changes and state updates.

And it will then also managed to stay for you.

So react will do that.

It all starts with you defining a reducer and you typically do that outside of your component so that

this reducer function isn't recreated whenever the component renders, because to reduce her function

oftenest decoupled from what's happening inside your component, actually.

So here.

We can have our ingredient reduced for, let's say.

And will actually bolt to reducers, by the way, but let's start with the ingredient reducer, and

this in the end stores a function.

This function will automatically get to arguments past by react to the state and you could name it state,

but I'll name it current ingredients.

So the ingredients currently stored by react and and action, that action will become important for

updating the state.

Now, you all know that concept of actions.

If you watch the reduc section actionis an object which could have.

A type, and then we can use a switch statement to define different cases for different code, you want

to execute for different types of actions we're getting.

For example, we could have a case to set our ingredients.

We could have another case for adding an ingredient, and we could have a third case for deleting an

ingredient.

Now, these are all just identifiers I come up with.

You can use any identifier you want.

You typically all should have a difficult case here, but we should never reached us, so here, I'll

just throw a new error.

Should not get there because we should actually handle all cases that we can have.

Now, a producer, as I said, needs to return something and will return different things for all these

cases here, we throw an error which also while cancels this function here, we're not returning an

error, but we return something new and that should be our new ingredients.

Now, if you call set, then I want to override my current ingredients with a new list, a new array

of ingredients, and that should be part of the actual object I'm getting.

So there I expect to get an ingredients property, which should be an array of ingredients which will

replace the old state.

Now, in the at case here, we all want to return a new state snapshot.

And our state here is an array.

Right, because ingredients is an array.

So we should return an array.

But here, of course, it should be our old array plus the new item.

So the logic is the same as we have it in our add ingredient handler.

And yet there we copy our old ingredients, then we add a new one.

So here in add, I copy my old ones, which are the current ingredients here, which I get automatically,

and then we add a new item and that has to be part of the action we're getting.

And now it's up to you, whoever you expect to get that all already merged into one object on the on

the action like ingredient.

Or if you got three different properties, you will be the one dispatching these actions later so you

can decide which data is in there.

And here I expect to get my ingredients into action.

Now, in the delete case here, we need to return our updated list of ingredients, so I'll take my

current ingredients and then again use filter, run some logic on every ingredient and compare the ingredient

ID with, let's say, the action I.D. So I expect to have an ID field on the incoming action, which

is the idea of the ingredient that should be deleted and therefore all ingredients.

Where does this not equal should be kept?

The one where it is equal will be dropped from the new list.

The new list is returned.

What we return here replaces the old state.

So that's our producer, the producer function.

That alone doesn't do much.

We now need to initialize it by calling use, reduce her or use it.

Utilize it by calling.

User, user, user, user takes our producer function.

So the ingredient producer in this case here and user user also takes an optional argument, which is

the starting state.

And in our case that's an empty array.

So that's what will be passed in as current ingredients the first timers would use for runs and for

subsequent runs.

Current ingredients will be our current state.

Initially, it's an empty array and user user like use state returns, something that something awls

is an array, but now not with state and set state, but with state.

So our user ingredients.

So we can comment about this.

Use State Coulier user ingredients.

But the second argument is now not a method to set our user ingredients.

Instead, we're doing the setting in our reducer.

Instead, it's a dispatch function.

It's still a function which we can call and you can name whatever you want to name.

Dispatch's just one that makes sense because it's a function which we'll call to dispatch these actions

later.

So where you dispatch these action objects which are then handled by the user.

So I'll temporarily again still import use state so that the area code still works, but let's now utilize

dispatch in the places where we previously call set user ingredients because we can't use that anymore.

We're not managing the user ingredients with use state.

Instead, here we now dispatch for a setting the ingredients and now here you need to dispatch an action.

The action could be anything, could be a string, but typically it's an object and here it's an object.

But we want to have a type property describing what action we want to do and then maybe depending on

which action we're running, some extra data like for setting our ingredients appropriate here.

So here, I'll dispatch an object with a type property type is set here, and of course, this has to

be one of the identifiers you're handling introducer.

So here's the set identifier and then this set action needs ingredients, property to work correctly.

So here I add ingredients and set equal to the filtered ingredients I'm getting.

And with that, we're using this to update our user ingredients.

Hentzen already have.

We saved us.

This would work.

But of course, we got to other places where we previously called set user ingredients like here, where

we add an ingredient.

We now instead call dispatch dispatch an action object where the type is at.

Again, that's the identifier we're using in the reducer.

And there we expect to get a ingredient property, so.

All add ingredient here, an ingredient is constructed as I'm constructing it here, so it's an object

with my ID and with the ingredient data I am getting here as an input to this function.

So now we dispatch this and finally for deleting instead of running this code, we also dispatch.

Action where the type is delete.

Again, because we have the lead type here and there, I expect to get an ID field in the actual object,

you could have multiple fields.

You don't always have to just have type and one hour field.

You can have as many fields in here as you want here.

However, it will be the ID and dad will simply be the well, the ingredient ID I'm getting here as

I input to my remove ingredient handler.

So that's now forwarded.

With that, if we saved us, this works our data loads and if I add, for example, apples that works

and to show that deleting all the works, I'll fix that error in my delete htp request by adding that

-- again.

And Jason.

And now if I click on, let's say, chocolate decis removed and it stays away if we reload.

So that's how we can use use, reduce her.