Original subtitles

One downside

of the validation we added thus far is our code.

Specifically, this line

we have this entered name is valid state.

And we start with true here, which implies

that initially we treat this as valid

and it turns out that that's not really the case.

We just set it to true

to not show does error state here ahead of time.

But actually we're cheating a bit here.

We're setting this state to avail you.

That's not correct because we know that we're not

going to really need that state for anything else.

Then outputting, whether it is this valid or not.

Now, why could this be a problem?

Well, imagine you had some useEffect

call in there where you do something.

Whenever entered name is valid changes

and specifically you do something.

If entered name is valid is true.

So if it's true, you wanna do something you wanna

in this case, log name input

is valid in a real application.

You might want to send an HTTP request here.

So let's say we add this.

And for this, I import useEffect.

If I do have that an open the developer tools

you see that this gets locked right at the beginning

before I did anything because of what I just explained

we incorrectly set this state here to true

and it isn't valid at the beginning.

That's just not correct.

We just did this as a work around,

to correctly show the error feedback.

Now, if you don't have, this useEffect case here,

you of course might be good with that

because then you have no real disadvantage

of using this trick.

But even then, I don't think this code reads nicely,

entered name is valid, is true.

Really? At the beginning,

it might be nitpicking,

but I'm not too happy with that.

I think it makes more sense to set this to false initially

because the input is invalid initially,

hence, we might want to add a third state here.

The entered name touched state maybe

and set entered name

touched

where we basically control

whether the user already did added the entered name,

input field.

And this all's is false initially

because initially this input field is untouched.

The user didn't do anything with it.

So now, we can use entered name touched

in combination with entered name as valid

to show this error message

and to add is invalid class.

Because now we don't just care about

whether the input is invalid or not.

But we also care about whether

the user had a chance of editing it

because if the user didn't have a chance yet

because the user didn't touch any input yet,

then of course there is no reason to present

this error.

For this. I'll add a new constant here.

Name input is invalid.

And for this all check,

if not entered, name is valid.

So that's the check we also have down there,

but I'll combine this with checking.

If entered name touched is true

because only if it was touched

and it's then is invalid.

I wanna treat it as invalid.

And now it's this name input is invalid Boolean

which you can use in this condition here

and also down here.

Though, now we have to be careful

since this is now name, input is invalid.

We of course need to invert,

our logic here.

Here, we don't check if it's not invalid,

but if it is invalid,

hence I removed the exclamation mark

and here I of course want to set this invalid class.

If name input is invalid

and not set it otherwise like this,

with that, if we go back and we reload,

initially, this is not showing this error state

but if I click submit, it's also not doing that.

And of course it's not doing that

because we never changed his touched state.

We now need to do that.

And it's now up to us how we want to change this.

And one change definitely is the form submission.

If the form is submitted,

all inputs are treated as touched.

Even if the user didn't type into them,

the user submitted to the overall form.

Which basically means the user confirms the overall form.

So we could treat all inputs as touched in this case.

So whenever the form is submitted

before checking the validity

just when it's submitted,

I will set entered, named touched to true

because all the inputs

and in this case we just have one input

are touched, are confirmed by the user.

When the form is submitted.

With this additive, we now click submit.

We get this error state once we submit.

And this is now a little bit of a better code.

It's more code arguably, but it's cleaner.

And it allows us to handle more use cases.

And it also allows us to ensure that code like this here

works correctly and doesn't run unexpectedly

just because of some strange work around.