Maximilian: 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.