All language subtitles for 005 More on useState() & State Updating_en

The way we use use state is correct, we're passing in a state, we're getting back this array which

restoring in this constant but the way we update the state is not correct.

There's one superimportant difference when you compare use state and how you work with state and functional

components to how you worked with state, state and to state and Class-Based components.

There's an important difference between these two concepts for use state.

As I mentioned earlier, you can manage any state.

It doesn't have to be an object.

You could just manage some text here.

But here I decided to work with an object because I have, well, two types of state or two input fields

which I want to manage now in class based components, you always had to use an object.

But there whenever you call set state, whichever object you passed into said state was merged with

your existing state.

So there if we passed it an object, the title property, it would be merged with our current state

and diamond property would not be lost, but simply title property would be updated and all old state

would be kept with U.S. state.

That's different, this updating function.

The second element of our array does update the state, but it does so by replacing the current state

with this, which in this case means if we type into the title, our new state simply is an object which

only has a title property and we drop the amount property.

Our new state is an object that simply doesn't have an amount property anymore.

That's why I'm getting this warning that the input of type number is uncontrolled.

That's our second input and I'm getting a warning regarding that input when we type into the first input,

because the second input does amount input here, which is of type no.

This, of course, refers to the amount property in our state.

Now, if we type into the first input, we update the state to now be an object which only has a title

property.

Hence the property we're trying to access on a second input, the amount property simply doesn't exist

anymore.

And that's exactly what's causing this error.

The solution is simple.

When we update the state, we have to ensure that we don't lose any old data.

That's not our responsibility because Riak doesn't merge that automatically for us.

And whilst this might sound like a bad change, whilst this might sound like it should do that for us,

you'll later learn why React actually doesn't merge does for us anymore because now we actually have

more flexibility regarding how we manage state.

If we decide to manage some object state, though, which very well might be the case in many situations,

we have to ensure that whenever we updated, we don't lose any old data.

So when we update the title here, we also have to set the amount property and simply set it to our

will current amount states or to the unchanged amount state by accessing input states zero.

So the current state snapshot data amount, for example.

On the other hand, when we update the amount, we should also make sure that we don't lose the title

by also setting this to input state zero DOT title.

Now, if you do that, if you make sure that when you update the state, you don't lose any information.

Now, if I type here, you see I get no warnings anymore.

And of course, this button doesn't do anything because we haven't connected it any more.

But these inputs are now working correctly.

Nonetheless, our code here, the updating code is not 100 percent correct yet reason for that is that

I'm accessing the current state snapshot on the first array element.

And of course, that does hold the current state snapshot for this renderer cycle of the component.

But the way react updates to state, we are not having a 100 percent guarantee here that our current

state snapshot actually is the latest state we committed.

And this might sound strange, but due to the way we react, renders components upon state updates and

so on, you could theoretically have a case where there's a lot going on on your page, let's say a

lot of animations or a lot of stuff that react decides to defer a state update until there's less work

going on.

And therefore, a user might be typing here into the title input before the latest amount input because

the user also typed into the amount input field a second ago before that state change has been rendered

to the screen.

Now, it's very unlikely for this to happen.

And in this simple application here, it will never happen, actually.

But in more complex apps, you could have a case where you're changing some state and your latest state

change hasn't been committed yet, hasn't been rendered to the screen yet.

Hence, if you have a new state change that also depends on your latest state snapshot, then you don't

have a guarantee that this state snapshot has already been well committed or created.

And therefore, this year, accessing our latest state value like this is not the ideal way.

Instead, does updating function?

So this function, stored and stored as a second element in your array, has an alternative forum which

you can use instead of just passing a value to that update function.

So to that function that sets a new state, you can also pass a function to that function and anonymous

function, for example.

But it could of course, also be a named one.

And if you pass a function here, which of course has to return your new state value in the end, and

I'm wrapping it in brackets here so that I can use this inline notation here, does inline error function

notation that after the Arrow business Disvalue, we're returning and we're returning an object here

without the extra brackets, this would be treated as the function body and this would simply be an

incorrect function body.

Now we indicate to JavaScript that this year is our function body and this is actually the return value,

which is just an object.

So now we're returning that object.

But in this function, which we're passing to this set state function here.

So to say there we get an argument passed in automatically by react.

And that's our.

Previous input state or whatever you want to call it, and wikinomics these brackets here, so here,

this function will actually tell react that we want to get the latest state that we set, even if it

hasn't been fully committed yet for this renderer cycle.

So now previous input state allows us to access this previous input state like this.

And the difference to using input state zero is that we're now not using the latest state, which has

been fully committed and which is used in this render cycle of this component, but that we're using

the latest state we set with an updating function, no matter if react already recreated the function

or not based on that last update.

So now here we have to guarantee that we get the latest state at all times.

That's, of course, what we want here.

And here are missing an extra bracket, by the way, to close that input, state one function.

So now this is the approach I always want to use down there for the amount of input we get, our previous

input state.

And then here we're returning a JavaScript object.

And that object can use that previous input state to set the title or the amount.

Now, is that have we safe that if we go back, you'll actually notice a strange behavior, though?

If you start typing, you'll get an error, and that error tells you that you reused an event, essentially.

Now, the problem here is that when we're passing a function to this function here, to this sad state

function in the end, then we're having this anonymous function here.

And that's that's a closure.

So that's simply a function that closes over surrounding values.

And in this case, it closes over our event here.

The event is fed into this on change anonymous function.

And in that function, which we have here upon a change, we're calling these sad state functions who

are calling a function.

But then I'm also defining yet another nested function here.

So we have a function, one which is our event function and function to which is our updating function.

Now, the problem with that is that if in this inner function here I use something from the outer function,

which I'm doing, I'm using the event, then this event will be locked in for the first keystroke,

essentially, which means that for subsequent keystrokes we don't use the new keystroke event, but

the previous one, which of course is then reused and which caused this error.

Now, normally that wouldn't be a problem, of course, because, yes, this inner function is state

updating function functions, a closure, and therefore it closes over a DEVANT object, which means

it saves this event object for its execution so that when does interstate updating function runs, which

happens asynchronously, we're guaranteed to use the event that was triggered for that keystrokes or

it was created for the keystroke.

The problem with events and that's now really exclusive to events and react just is that react events

are not the native theme events, but special synthetic events created by REACT, which basically replicate

the native DOM events he would normally get.

But react adds a special factor to that.

It pulls these event objects, which simply means it uses event objects.

So instead of creating a new event object for every keystroke, it instead reuses the previous object.

And the consequence of this is that for the second keystroke, since we have a closure and we locked

in the event for the first keystroke, for the second keystroke, we still reuse that same object we

had for the first keystroke and dead Sibley's.

The problem here, we're reusing the wrong event object because of the way react handles event objects.

Now I'm aware of this sounding very confusing.

In the end, this is really a special case because of the way React handles this event object.

The solution is that outside of this sets that function, we create a constant, for example.

Which we hear on the title could call new title and their iStore event target value.

Now, this will be recreated whenever we're typing.

And now we need a real function body, though.

So we need to wrap this into curly braces, because now we actually have more than one line.

We're not just for turning something.

We're not just executing one expression.

What we have two statements here.

So now here I'm storing the new title for every keystroke and now this here.

This sets that function with this nested inner function can use new title.

And this will therefore now close over this new extract, a title for every keystroke, instead of using

that same event all the time, that same event object.

Of course, we do the same for the amount they are, we now need curly braces around this entire function

expression year then.

We got our new amount from event target, not title value here.

And the amount now is simply a new amount, again, simply because we're using a closure here and we

want to make sure that we're generating a new amount for every keystroke, and then this will automatically

be considered by this inner function instead of reusing that same event object all the time.

Now that we can save this, go back and now start typing here and that now all works.