Original subtitles

We know how React manages state,

or at least we have an idea.

But there's one thing which is important,

which I mentioned before,

but which I now wanna emphasize again.

And that is how React handles state updates.

In your code, you might have a component

and in that component, you might manage some state

with the help of the useState hook,

and therefore React manages that state for you.

Let's say the initial state

for this product component is DVD.

So we have a DVD as a product here.

Now eventually, because a user clicked a button or whatever,

in that component we update that state.

For example, with SetNewProduct,

that could be our state updating function

returned by the useState hook

and we set the new product to book, so from DVD to book.

Now what happens with that is not that DVD is instantly

after SetNewProduct finishes execution is replaced.

DVD is not instantly replaced

just because SetNewProduct is done running.

Instead, calling SetNewProduct,

and calling those state updating functions in general

schedules a state update with the data book.

But that's now a scheduled state change,

React is aware of it, React plans on processing it,

React doesn't process that immediately though.

Now in reality most of the time, state changes,

scheduled state changes will be processed very fast,

pretty much instantly.

So in reality, it might feel instant.

If we click a button and dad removes a paragraph

to us as a human, that happens instantly.

But React reserves the right

of actually postponing that state change.

For example,

because a lot of other performance intensive tasks

are going on at the same moment,

potentially it asks that,

React considers to have a higher priority.

Let's say on your screen, you have a input field

where the user is able to type something.

Reacting to that user input would have a higher priority

than changing some text on the screen.

And for reasons like that,

React might postpone scheduled state changes.

Now, what React does is,

it guarantees you that the order of state changes

for one in the same type of state is guaranteed.

So if we call set new product again

and we set this to, let's say, carpet or whatever,

then this state change would not be performed

before the previous state change.

So the order is kept,

but it's not necessarily executed immediately.

Eventually of course it will be processed

and your new state will be "Book."

And once that new state is active,

once that state change was processed,

React will reevaluate the component,

it will re-run the component function.

Now, because of that scheduling

where of course you might have multiple outstanding

scheduled state changes at the same time,

because of that,

because multiple updates can be scheduled at the same time,

because of that,

it is recommended that you use this function form

for updating your state

if you depend on the previous state snapshot.

In a lot of cases, this will probably not matter

because it's processed so quickly

that you can't even click fast enough to see a delay

but because it theoretically could be postponed,

this is the safe way of ensuring

that state changes are processed in order

and for every state change

where you depend on the previous state,

you get the latest state.

Otherwise you might just get the latest state

when the component function was executed last,

which is not necessarily the same state

as if the state changes are executed in order.

Because if you have multiple outstanding state changes,

they all come from the same last re-render cycle

of that app component.

They all come from the last component snapshot,

but of course, if they were processed,

the component would re-render in between

but since they're all already scheduled,

all outstanding states changes

don't take that new in-between

component result into account.

That's why this function form is helpful

because there React will actually ensure

that for every outstanding state change,

it looks into the latest state and gives you that

and does not use the latest state

from the last time the component was re rendered.

That's an important difference

between when the component was re-rendered

and when a state change was scheduled.

You can have multiple outstanding state changes

from one and the same component re-evaluation.

That's the key takeaway here and that's why this matters.

That's also why in the last non project module,

where we initially learned about use of fact and so on

it was safe to actually update our form validity

based on the email and password is valid states

instead of use effect,

because just like using the function form

for updating a state based on a previous state snapshot,

useEffect actually because of its dependency mechanism

is ensured to rerun the effect here

every time a state or a value which is a dependency changed.

And therefore you can't miss outstanding state changes

because here it will simply rerun this effect

for every time to component was re executed

the component function was re executed.

It will thereafter always rerun the effect

and therefore you are also guaranteed

to get the latest state when doing it like this.

So these are simply two different patterns

for dealing with one at the same problem you could say,

depending on what you're trying achieve.

Here we want to state updates

that depends on some other states.

In this case, on the other hand we want a state update

that depends on the same state

just a previous snapshot of that state.

So that state updates scheduling

is a mechanism you have to keep in mind,

not because you actively need to do something about that,

React manages those scheduled updates for you,

but because you need to write your code accordingly

to rule out any danger of potentially working without data

you rule it out when using that,

you rule it out when working with useEffect.

Now, there is another important thing you need to know

about state in react.

There, we actually have this nav context

and in the navigate handler I do something which you see

a couple of times throughout this course.

I call two state updating functions after each other.

Now we just learned

that just because you call such a function

does not mean that in the very next line

the state was updated.

State was not updated here.

Instead, we just learned that the update will be scheduled

and eventually the entire component will rerun.

So this component in this case

and then once this component rerun

then we have the latest state available.

Not earlier.

That's what we learned.

Now here however,

we have two state updating functions after each other.

That clearly means that two state updates will be scheduled.

Does this, however,

also mean that the component will be re-executed,

re-evaluated twice.

You could imagine that this happens

but that's actually not what React does here.

Instead, if you have two state updates

in the same synchronous code snippet after each other.

So not in a promise in different than blocks

but in the same function, for example,

where nothing in between would cause a time delay

or anything like that.

So if you have two synchronous lines

of code after each other,

where you would then call a state updating function

in such cases, React will batch those state updates together

in one long synchronous process,

so for example, in one function that executes start to end

without any callbacks or promises in between,

in such cases React will take all the state updates

that are produced by that function

and it will batch them together into one state update.

So back in this picture,

even if we would not just update the new product here,

but if we would update something totally different

in the same function,

we would still just have one scheduled state change

which then however, just changes two different states.

But it's one process.

It's not two scheduled changes

with two upcoming component, re-executions re-evaluations,

but instead it's one scheduled change

where all the different states

you might want to effect are simply batched together.

So state batching is another important concept

you have to be aware of when working with react.