All language subtitles for 008 Introducing useReducer & Reducers In General_en

Now we just learned about useEffect,

which I mentioned would be the most important

React Hook besides useState.

Are you ready for the next React Hook, useReducer?

Now, useReducer is another built in Hook

and it will help us with state management.

So it's a bit like useState,

but actually with more capabilities

and especially useful for more complex state.

Because sometimes you have more complex state,

for example, multiple States that kind of belong together,

that are managing the same thing

just different aspects of it.

Or you have multiples states

that kind of change together

or are related.

In such cases,

useState and the state you get from there

often becomes hard or error-prone to use and manage.

And it's easy then to ride bad

or inefficient or potentially buggy code,

which is of course it's never what we want.

useReducer is then an alternative to useState.

So it's a replacement,

if you need a more powerful state management.

Now, this does not mean

that you should always use useReducer

because it's more powerful,

so it's always better.

No, because it's also a bit more complex to use,

It requires a bit more setup.

So for a lot of scenarios for the majority

I would argue you probably use useState.

But there are cases where the extra work

of getting useReducer to work,

is just worth it.

That's all very abstract.

What would be a concrete example?

We can again, go back to the good old Login.js file here.

Here, you see I'm managing a couple of states snapshots,

and you might be able to spot some related state here.

We managed the enteredEmail and the enteredPassword,

but then we also managed the fact or the question

the response to the question,

whether the email or the password is valid.

And we managed the overall form validity.

So you could argue that overall,

this is all one big state

that describes the overall form state.

The inputs are part of that,

or you at least treat every input

as one entity and one state,

which simply has two aspects.

The value the user entered

and the validity of that input.

And it becomes clear that we have some work to do

and some redundancy if we consider the fact

that we're setting the overall form validity,

by checking the validity of email and password

when we're doing the exact same thing here

for our two validate handlers.

Now we could rewrite this in various ways.

And for example, use our emailIsValid

and passwordIsvalid states here in this useEffect

and just use those two states to confirm

whether the overall form is valid

and that it would work.

But nonetheless, we at least have these two states,

the entered email in this example,

and the validity of the email

that clearly kind of belong together,

and which we therefore might wanna manage together.

In addition, I wanna come back to something

which we don't have any more

because we're using useEffect,

but what we had before.

If I commit out useEffect here

before you might remember

that inside of email change handler,

and password change handler,

we had a slightly different code.

We had this code here essentially,

not just in the email change handler,

but also in the password change handler

where we checked the other entered value

and entered value for this handler

with event target value,

and we would derive the Form validity from that.

Now this approach also worked,

but we had some code re-usage,

which is why the Effect was a better result

But let's say for whatever reason

you don't wanna take that route to useEffect.

In that case, you would have a number problem

and I'm just going back to the solution

to show you this problem,

which you can have in some apps

and in some use cases.

Here we are updating some state

the Form validity state,

based on two other states.

Now, what did you learn about

updating the state based on some older state?

You wanna use the function form, right?

Notice doesn't work here however,

because that's only true if your next state update,

depends on the previous state snapshot of the same state.

But here we depend on two other states' snapshots

of different state of the entered email

and the enter password,

not on the last state snapshot of the form validity.

So therefore here actually we're doing something

which you normally shouldn't do.

Because of the way React schedules state updates,

this code here could actually in rare cases,

but it could actually lead to the scenario

where this runs before,

for example, password state update was processed.

So therefore enteredPassword

when this code runs,

might not contain the latest entered password,

because of how React schedules state updates.

That's what I preached before,

and why I urged you to use the function form.

But again, it's not available here

because we're depending on two other states

and not the last snapshot of this form validity state.

This is another scenario where you could use useReducer.

So it's a good use case,

a good replacement of useState.

When you have states that belongs together,

like here, with the entered value

and the validity of the value

and or if you have state updates

that depend on other state.

And actually we don't even have to go back to this code.

We already violate this rule of using the function form

if a state update depends on an older state.

Here in our validateEmail

and validatePassword handlers.

There, we are calling setEmailIsValid

and setPasswordIsValid,

to set new states,

for this emailIsValid

and passwordIsValid state.

These are our two states,

which we're setting there.

Now, how are we setting these states?

Well, by having a look at another state

and calling a method on it.

We're having a look at the enteredEmail state,

which is a different state.

This is our enteredEmail state.

It's a different state than our emailIsvalid state.

Sure, they are related.

They both changed because of what the user entered,

but technically these are two different states,

two different variables.

And we are deriving our new emailIsvalid state

by looking at another state

and that is something we should not do.

It works in most cases,

but in some scenarios it could not work

because maybe some state update

for enteredEmail wasn't processed in time.

And then we would try to update emailIsValid,

based on some outdated enteredEmail state.

So we should use the function form here,

but again, just as with a setFormIsValid we can't,

because with the function form

of our state updating function here.

We only get the latest state

for that state which we're setting here.

So we would get the latest emailIsValid state

not the latest enteredEmail state

if we use the function form here.

So that's why this is not an option.

And therefore here we are already violating this rule

which I told you to well not to violate.

And that is a scenario where useReducer

is always a good choice.

If you update a state,

which depends on another state,

then merging this into one state could be a good idea.

And you can do that without useReducer as well.

You could simply manage an email state,

which is an object with the value

and the valid being part of the same object.

You could do it with the useState,

but in such cases

when your state becomes more complex,

bigger and combines multiple related states,

useReducer can also be worth a closer look.

And that's why we'll dive into it in the next lecture.