Original subtitles

So in the last lecture I showed you

how you can use one state instead of multiple states.

And I did talk about it there.

Now the way I'm updating my state here

is not entirely correct though.

It technically would work,

but in niche cases it could fail,

and it's simply not a good practice to update it like this.

So what's the problem here?

Here, I'm depending on my previous state

for updating the state.

In this case, we depend on the previous state

because we used this one state

instead of three-states approach

and we need to copy in the other values

so that we don't lose them.

Hence we depend on the previous state snapshot

to copy in the existing values

and then just override one value with a new one.

Now whenever, and that's another key rule

which you should memorize,

whenever you update state

and you depend on the previous state,

so for example, as we do here in this object,

but also if you would be managing a counter

which you increment by one, for example,

whenever you update your state

and you depend on the previous state,

you should not do it like this

but you should use an alternative form

of this state updating function.

Instead of calling it like this,

you should call it and pass in a function to that function.

So you call the setUserInput function

and you pass a function to it,

for example, such an anonymous arrow function.

And this function, which you pass to setUserInput here,

will automatically be executed by React.

And it will receive the previous state snapshot

for that state for which you're calling

the updating function,

so in this case, for this object state here.

So we'll get the previous state snapshot,

and now here, we should return the new state snapshot.

So instead of this function

which we passed to the state updating function,

we return the new state now.

And that now could be,

or in this case, should be, our object

where I copy in the key value pairs from the previous state

with the spread operator,

but where we then also override,

in this case here, enteredTitle with event.target.value.

Now why should we do it like this instead of like this?

In many cases, both will work fine,

but keep in mind that I mentioned

that Reacts schedules state updates,

it doesn't perform them instantly.

And therefore, theoretically,

if you schedule a lot of state updates at the same time,

you could be depending on an outdated

or incorrect state snapshot

if you use this approach.

If you use this approach, React will guarantee

that the state snapshot it gives you here

in this inner function,

will always be the latest state snapshot,

keeping all scheduled state updates in mind.

So this is the safer way

to ensure that you always operate

on the latest state snapshot.

So you should use this function syntax here

whenever your state update depends on the previous state.

That is something you should memorize.

If your state update depends on the previous state,

use this function form.

With all of that though,

I wanted to show this because these are key concepts

which you're also going to see again and again

throughout this course

and throughout a lot of React projects,

but here I will actually comment out

all of these alternatives

and I will switch back

to that multiple states approach instead,

which we initially had.

So let's comment out all of that

and go back to this initial approach.

I just wanted to show the alternative

because it is a valid alternative,

you will see it in many projects,

you will have scenarios where you need it.

And this thing regarding the,

if you depend on the previous state,

use this approach thing here,

that's something you should keep in mind in general,

because you will often depend on a previous state,

not just if you merged state like this

but also in other scenarios,

like the counter which I mentioned, for example.

So that's why I mentioned this.

Nonetheless, let's go back to this multi-state approach now.