Original subtitles

The question now is what do we want to do

with that value?

What's the goal now?

And the answer is, well, we want to make sure

that we store it somewhere so that when later

when the form is submitted, we can use that value.

Because of course, we want to gather all the values

for all inputs and then combine them

into an object when the form overall is submitted.

And one way of storing that value

and making sure that it survives,

even if that function would be re executed

for whatever reason,

so this component function, I mean.

To make sure that we store the value and that it survives

if that function would be re-executed

and the component would be re-evaluated,

we can again, use State.

So we can import the useState hook from React here,

and basically just call it here

at the beginning of the ExpenseForm function

and set the State for this input here, so to say.

And initially that's an empty string

because initially when this component is rendered

for the first time, nothing was entered,

but then we can again, use destructuring

to get our two elements,

which is the currently enteredTitle.

Maybe we name it, enteredTitle

and a function for updating the State,

which following the convention

should be named setEnteredTitle.

And here, when we react to this event

where the user enters something,

we can't just call setEnteredTitle

and pass events target value.

So the currently entered value as a parameter,

as argument, to setEnteredTitle.

And therefore this will be stored in our State.

Now, here I'm not really doing it to update this component

though the component will update.

That will always happen when you update the State

but I'm doing it to ensure that we're storing

this in some variable, which is kind of detached

from the life cycle of this component function.

So that no matter how often this component function

might execute again, this State is stored and survives.

There would be other ways of solving this as well

but that works just fine.

And it has another advantage

because we'll need that State for updating

and for re-rendering that component later anyways.

But for the moment we just use a to safe to value.

Now we can do the same for the other two inputs.

And of course, definitely try this on your own as well.

Pause the video and make sure you listen

to these change events for the other inputs as well

and that you also store State for those changes.

So here's your chance to pause the video,

thereafter, we'll implement this together.

So, did you add that?

Let's now do it together.

And I'll start by adding a new function

and that will be the amountChangeHandler.

And the logic is basically the same as before.

I want to make sure

that this function gets triggered

whenever the amount changes.

So on the amount input, we can add a onChange prop

and point at the amountChangeHandler, just like that.

And before I add any code in there,

I will already add the third function

for my dateChangeHandler, like this

and that should be triggered whenever the date changed.

So here I always listened to onChange

and point at the dateChangeHandler.

So now all these inputs are wired up

but of course at the moment nothing is happening here.

Now I also of course

want to store State for changes made here.

And that brings up one important question.

Maybe a problem you also encountered,

how can you manage more than one State?

It is something we have learned up to this point

but it turns out that it is rather simple.

You can call useState more than once.

Maybe you tried that and if you did good job,

because you can do that.

You can have multiple States, multiple States slices

or State pieces per component.

And all of these States inside of one at the same component

will then all to be totally separated from each other.

So you're all called useState again

and extract my enteredAmount

and my setEnteredAmount function with RAD structuring.

And now we've got these two pieces of State

which belong to this component

and we can update and read them individually.

So they work in a totally separated way.

When I update the amount,

this will not affect the title and vice versa.

So for the amountChangeHandler,

we can call setEnteredAmount

and pass in event target value here as well.

Well, and unsurprisingly, we can do the same for the date.

Call useState again

and store an empty string here as well.

By the way, I'm storing strings all the time

and not a number here for the amount, for example,

because by default, whenever you listen to the change event

for an input, if you read the value of that input element,

it'll always be a string.

Even if it stores a number

it will be a number as a string and the same for the date.

So we always get a string here.

That's why I also initialize all States with a string.

And here, therefore, for this third State,

I have my enteredDate and setEnteredDate.

And I now also can update this State here

with setEnteredDate events target value, like this.

Okay.

Now we got these three State slices

and this is really important.

This is absolutely okay

and you will see that quite a lot,

that you have more than one State per component.

You can have these separate States and update them

separately and manage them separately.

That is a key part of this entire State concept

React ships with.

You can, and you often will have multiple States

per component.

Nonetheless, this multiple States

verses one State thing is a concept

I wanna take a closer look at.