Original subtitles

So, were you successful?

Let's do the same for the password.

Of course it should be fairly trivial.

We create our passwordReducer

which is an anonymous function

that gets the last state and the action.

And, yeah, well, we can just copy this, can we?

We can copy this in here.

The validation code needs to change

because for the password,

I'm checking the length.

So, I wanna copy this code down there

and use this here and here.

The action names can be the same,

but now of course

we also need to call useReducer again here.

Now, for the passwordReducer

and what we get back therefore is the passwordState

and the dispatchPassword function.

We also wanna set an initial state

which can be the same one as here for the email of course,

just as object with no value and null isValid state.

And now, we simply have to update the code accordingly,

setFormIsValid,

here I'm not interested in the enteredPassword,

but instead, now that we do validation in here,

I only want to access my passwordState

and there the isValid prop.

And when the password changes,

I want to call dispatchPassword,

pass an object where I have to USER_INPUT type

and the val field which is the event.target.value.

And here, when the password field blurs,

I also have dispatchPassword

and the type is just INPUT_BLUR.

And here, I'm not caring about the enteredPassword

but the password state

and the value entered by the user.

And then we can go down,

and for the password field here,

we have passwordState.isValid in our check,

and we feed back the passwordState.value

into the input field.

And if I go up,

we see, we use nothing here,

so we can comment out these two useState calls.

And with that,

again, if we give this a try,

this all should work just fine,

and it does.

Now that wasn't too difficult hopefully,

it's again the same what we did for emailReducer.

And, of course you might see potential here

for using just one reducer function instead of two

because it's almost the same.

The validation logic is different though,

so that's definitely refactorable

but it takes a little bit more work

which is why I'm not going to do it here.

But generally, it's not too far off.

And in addition,

and that's the thing that matters more to me here,

the foreign validity,

of course also is a bit related to the input validity

because the inputs are part of the overall form.

So the code we have here is still not optimal

because we still derive the foreign validity

off of upper state,

which is still not what we want

due to the reasons I explained earlier

with React's scheduling the state updates.

So we might still refer to an old state here

that does not change

just because the state

is coming from useReducer setFormIsValid,

like this still is not optimal.

And in addition,

having our state that is split like this

even though it's technically belongs together

is also not something you might want.

Now, whether you want this or not is up to you,

but the fact that this is not optimal is a fact.

So for this,

let's comment this out again,

and let's go back to the use of fact solution

which actually is a nice solution.

So we can go back to this,

and just update it accordingly.

Here, we have to emailState

and there simply isValid.

Instead of doing validation here,

and the same for the password,

we have the passwordState.isValid,

just like this.

And hence here,

we care about the emailState

and the passwordState.

And this what now be a fine way

of calling setFormIsValid,

because since it's now inside of an effect,

we still refer to our state snapshots,

but this effect is guaranteed to rerun

whenever these states change,

and therefore ultimately,

it will run with the latest state values.

So this actually is now an okay way of updating a state

based on other state

because with use effect,

we're guaranteed that this will run

for every state update React performs,

which was not the case before

where maybe the code ran too early,

useEffect only runs after state updates.

So here, this is okay.

Now, still here,

we have a problem though,

which is why I'm showing this to you.

This now will run accordingly and correctly,

and hence here indeed,

if I enter something here,

eventually does unlocks and works.

But, the problem we'll have here is,

that this effect runs too often.

This will run

whenever the email or the passwordState changed.

Now that includes cases

where maybe just the value changed,

which might not be what we want.

We actually only care about the validity here.

Now it turns out that we updated the validity,

now whenever the value changes as well.

But, of course, if, for example,

the input was valid already,

and we then add an extra character to the password,

it doesn't really change.

It was valid before with the extra character,

it's still valid.

So here, for example

if I have a password that is valid,

if I add one more character,

it's still valid.

Nonetheless, our effect re-executed here.

Now that's something we might wanna avoid

and it re-executes at the moment

because our dependency

is the entire email and passwordState,

not just the validity part of it

which is actually the part we're interested in.

Here, we can use a technique,

which you need to know

which is why I'm showing it to you.

We can use object de-structuring,

so the same as array destructuring,

just with objects,

to pull out certain properties of objects.

For example, from emailState,

we can extract isValid,

and store it in a new constant of the same name.

And we can do the same for the passwordState.

But since I'm already using isValid in this constant now,

we can use a variation of the object de-structuring syntax.

We can add a colon here,

which now won't assign a value

because we're not creating an object here.

We're using it on the left side of the equal sign.

This is simply the syntax for object de-structuring.

And with the object,

we now assign an alias to de-extract that value,

to de-extract the property.

So we're pulling out the isValid property

but we're storing it in a constant

which actually could be named emailIsValid.

At the same here for the password,

we're pulling out the isValid property

but we can store it in,

let's say a passwordIsValid constant.

So this is an alias assignment.

This is not a value assignment,

it's an alias assignment

because it's part of this object de-structuring syntax

which is the syntax you're automatically using

if you're using those curly braces

on the left side of the equal sign.

And now we have the email and passwordIsValid constants

which we can use here,

as our dependencies,

and as our values,

your dependencies should be matched by your values

and the other way around.

So emailIsValid and passwordIsValid.

Now the advantages that since now,

I'm pulling out the isValid state here,

whenever just the value changes

and the validity did not change,

this effect will not rerun.

And you can see this,

if I enter something here,

of course, in the beginning,

it will run.

But once the passwordIsValid,

if I'd have one extra character,

you don't see an additional checking for

in validity output,

this is especially clear if I clean this.

You see, I can type a lot of characters,

this never checks again

because the validity did not change.

Of course, that's not the case if I make it too short.

So, I wanted to show this

because this is an important concept

to further optimize useEffect

and to avoid unnecessary effect execution,

not just when using it with useReducer,

but for example, also when doing so.

Andother use case could be,

if you have props as a dependency for your effect.

You don't wanna rerun the effect whenever prompts change.

You only wanna do

is when some prompts change,

for example, with object de-structuring,

you can get there.

So that's a little step back here to use a fact,

but an important one,

an equally important concept,

of course, was useReducer though.