All language subtitles for 004 Dealing With Form Submission & Getting User Input Values_en

Now, for all of that,

let's come back to this simple input component,

and let's start with getting the user input here.

And let's then also validate that input

and potentially show an error message to the user.

And then we're going to explore

the different ways of validating.

So the different triggers for validating,

to find out where the differences are,

and how we might best be able to combine everything.

So let's start with fetching the entered value,

the user input.

And there are two main ways for doing that.

We can listen on every keystroke

and store the value in some state variable, so to say,

or we use a ref to fetch the input

once the user is done typing in a value.

And I'll show both here.

Of course, in reality,

you would only use one of the two approaches,

but here I'll use both.

And hence I will import use ref and use state from react.

And then here, we'll start with state.

I can set up a new state, my entered name, let's say,

by calling use state.

And initially it's an empty string.

And then we can update this entered name

with set entered name on every keystroke,

or on every change that occurs here on this input element.

So here we can add a name input change handler,

such a function, which receives the default event object.

That's how JavaScript in the browser behaves.

Once we bind this function

to the on change event on the input,

we automatically get an event object describing the event.

And from there, we can get the entered value.

And therefore, we'll be able to

set the entered name to event.target.value.

And that's vanilla JavaScript

that we have access to this entered value

on the event target, which will be this input.

And event target will be this input,

because we can now bind the name input change handler here

to the on change event.

So that on every keystroke, this is fired,

and hence the entered name state is updated.

Then we can add a second function here,

the form submission handler.

And this as the name implies is triggered

once the form is submitted.

And there we also will get an event object

because I'll bind this function

to on submit on this form, like this.

Now, here's one very important thing here

you have to watch out for.

And that is that on event,

you should call prevent default here,

because again, we're dealing with some vanilla JavaScript

and browser behavior.

And the default behavior by the browser is

that if a form is submitted with a button

instead of a form, a HTTP request is sent to the server

serving this website.

That happens automatically.

The browser does this automatically.

It sends an HTTP request to the server,

which is serving this website.

The problem with that is that here,

we don't really have a server

that wants to do anything with that request,

we just have a static server

that serves our JavaScript and HTML files.

So we don't want this request to be sent,

and hence on this event object,

which we get automatically passed into this function

since we've bounded to on submit, on this event object,

we can call prevent default to tell the browser

to not do that default behavior,

to not send this HTTP request, and instead to do nothing.

And we need to do that

because if that HTTP request would be sent,

it would lead to the page being reloaded in the end,

and we definitely don't want that,

because that would restart the entire react application,

we would lose all our state,

and we would definitely not have the behavior we want.

So that's important.

Then as a next step, now that we can guarantee

that the page won't be reloaded

and the app won't be restarted,

we can console log the entered name.

So the last name we stored

because of our input change handler.

And if we now saved at all,

and I go to my console here, I can type Maximillian here.

And if I hit submit, that gets logged to the console.

Now, the alternative approach would have been

to just set a ref on the input

and read the value from the input when we need it.

So since I'm importing use ref, we can implement this

by adding a name input ref constant, for example,

and assigning the value of calling use ref to it.

And then we set name input ref

as a ref to this input with the special ref prop

which react allows us to set on any HTML element.

And here I then set name input ref as a ref.

And now with that ref set up, when the form is submitted,

we could have also gotten this entered value

by reaching out to the name input ref,

and accessing current.

On react refs, you always have a current property

because refs are always objects with a current property,

and it's this current property

which then holds the value you assigned to this ref.

So in this case, a pointer at this input element,

that would be stored in current.

So since the value and current is that pointer

at the input element, we can also access.value here

because input elements in JavaScript,

the JavaScript objects representing

these HTML input elements always have a value property

which holds the value currently entered in that input.

So that's how we can read that entered value

from that input.

And we can store it as an entered value,

and then simply output this here.

And if I do that and I reload and I type max,

we see max twice, the first output is coming from our state,

the second output from our ref.

Now, in reality, you, of course, wouldn't do both.

You would do one of the two approaches,

either every keystroke logging with the state,

or something similar, or you use a ref

to read the value when you need it.

Now, how do you decide which one to use?

It depends what you plan to do with the entered value.

If you are only interested in it once

when the form is submitted, a ref might be better

because logging and updating the state value

with every keystroke is a bit overkill then.

You don't need to do that

if you only want the value once.

However, if you of course need the value, the entered value

after every keystroke, for example, for instant validation,

then using the state is better

because with a ref you can't really do that.

Another reason for using a state instead of a ref could be,

if you want to reset the entered input.

Let's say here at the end of the form submission handler.

There we can reset the entered name

by calling set entered name

and setting this to an empty string.

And all we now need to do is bind the entered value

back to the input through the value prop.

The entered name is now bound to the value prop on input.

And hence, if we update the entered name,

that will be reflected here.

This works great when using state,

but it's not really possible with refs,

at least not as elegant.

With refs, you could also use your ref

and access the input element which is stored in that ref,

and set value equal to an empty string.

But this is not an ideal way of doing it.

It works, if I comment out this, it works as you can tell,

but it's not ideal

because we are directly manipulating the dom here,

we're using some vanilla JavaScript code

to directly reach out to the dom and change something there.

And that is typically not something you should do.

You should leave that up to react.

React should be the only thing manipulating the dom.

And therefore this is not ideal, don't manipulate the dom.

You can do it and it might be okay,

it's up to you ultimately,

but it's not a very clean way of using react.

So, that could be another reason for using state,

which you'll potentially update on every keystroke,

because maybe you want to reset the entered value.

But that's not even the main topic of this module.

Now we know how we can get the entered value

and when we might want to get it.

But this module is about more than that.

It is mainly also about validation,

and that's something I wanna dive in next.

How can we validate this user input,

and how do we best do that?