Hello, everyone, and welcome back.
In this lesson, we're going to talk about angular on push change detection and push change detection
is faster than the standard of angular change detection, but it's also trickier to use.
So there is a tradeoff going on here.
Let's have a look at on push change detection in action.
We are going to start with this example that we have built on our last lesson where we have here the
key event getting detected, trigon here, the untitled changed method that is mutating directly, the
coarse object, which is an input to the Kosaka, even though we are directly mutating here, our plane,
JavaScript Object Angular, will still correctly reflect here the result on the screen because angular
in default change detection is comparing the previous values here of the course description expression
with the current latest value.
And if it detects a difference, then Angular is going to update the view.
Let's now switch here to a different change detection strategy.
We're going to head over here to our component and we are going to specify here that we are now going
to use on push change detection.
Let's not try this out to see what happens if we now start editing here.
The title of the course, we are going to notice that still we have here the same results.
So it looks like on push change detection is still working exactly the same way as default change detection.
And indeed, in this particular example, they work exactly in the same way.
So this is a similarity between the two types of change detection.
Both mechanisms are triggered in response to an event handler.
So in both these situations, ANGULAR is going to make sure that the latest value of the model gets
reflected here on The View.
Let's now see a scenario where the two change detection mechanisms work differently.
Let's head over here to our application component.
And this time around, let's try to mutate the object.
But let's not move to the course object from an event handler from inside the car scarred component.
Instead, let's quickly create here a div with a class demo and let's add here a button.
We are going to give some text to the button.
We are going to add here the edit course button.
And in response to a click on this button, we are going to be mutating the course object and change,
for example, the title of the course.
So when this button is clicked, we are going to add here an event handler.
We are going to call it on edit course and let's quickly implement it here at the level of the application
component.
We are going inside this on a course for Axis here.
The courses three.
Let's say that we exosphere the first position of the array.
So this is going to be the first Karith here on the screen.
And we are going to mutate here the value of the description of the course.
We are going to try to assign here a new value.
So let's now try this out.
We are going to reload our application and we will see what happens whenever we click on edit course.
So if we click now on edit course, we are going to see that even though we changed here, the description
of the course to a completely different value, that change has not been reflective on The View.
As you can see, we have here a view synchronization issue which is being caused by the use of the on
push change detection in order to confirm that that is indeed the case, that the change detection mechanism
is what is causing this problem.
Let's reload here our application using the default change detection mechanism.
And this time around, whenever we click on edit course, the value of the course title is getting reflected
correctly on the view as expected.
If we activate again on push change detection and we click here in our edit button, we can see nothing
is happening.
So this confirms that it's indeed caused by the use of on push.
So the question is what is going on here and how can we use this change detection mode?
We know that it's faster, but we can also see immediately from this example that in many situations
is going to be a bit harder to reason about if we don't take certain precautions while building our
application.
As we can see with the default change detection, even if we click here on a button at the level of
the application component, Engelhard is still going to go down the whole Iraqi tree and shake all gelled
components to see if an event trigger at the level of the parent component.
Also, by any chance, change the data that would affect the view of the twelve components.
On the other hand, while using on push at the level of the cursor, we can see that these Kirchherr
will not get updated if some parent components accidentally mutates the data that the cursor is displaying.
We can already see that one of the features of unpunched change detection is that a.
Part of the componentry is not reversed and checked for changes under certain circumstances.
We can clearly see that these cuts here by some reason are not getting checked for changes in the data
model.
But the question now here is, how does this work exactly?
Well, let's continue here.
Our example.
So going back here to our David Kurzawa, then let's try something different.
Instead of mutating here, the description of the courses object directly, just mutating the JavaScript
object.
Let's see what would happen if we would create here a copy of the course object.
Let's then start by creating here a reference to the object that we want to modify.
So as we know, we want to modify the first item of the courses array.
Now, what we are going to do is we are going to define a new variable called New Course.
These new course will contain the new value for the description.
And this new course object is a copy of the course object.
So we are going to create here a copy using here the object spread typescript notation.
Now that we have here a new copy of the course, we are going to mutate the copy.
So the difference here is we are not mutating an existing object that already existed in Siberia.
Instead, we are mutating a copy that we have just created and we're going to assign each year the new
value.
We are going to add here that any type so that we don't get here a compilation error now that we have
here our copy of the course that has been mutated and modified with a new description.
What we are going to do is we are going to assign in this position of the array the copy that we have
just created.
So the new course variable that we have available here.
Now, let's see how this works.
So there's a big difference here.
We are not mutating an object directly.
We're going to create a copy in order to add here a new description if we now click here on the edit
course.
But then we're going to see that this time around, the new value is getting reflected on the screen.
Based on this example, we can see that the cursor component got rearranged on the screen whenever one
of the input values of the component has changed.
So before we did not change the input of the components.
Instead we were mutating directly and nested property in the course.
But the object itself was exactly the same.
Only one of its properties were being mutated in that case on purpose, did not trigger a new re of
the view.
But in these new case where we created here a copy of the curses object.
So essentially we provided here to the cursor a completely different object.
So we got here a completely different input to a different JavaScript object.
This time around, we got here a successful rendering of the view and we have displayed here the new
value on the screen.
So let's quickly summarize how on push detection works from what we have seen so far.
The first one of the main differences is that if our component is using on push, then ANGULAR is not
going to try to detect changes on the input data by analyzing each of the expressions of the template
instead of ANGULAR is going to try to detect changes in the input data over the component.
We have also seen that if an event handler gets triggered, then on push change detection is going to
be triggered just like the case of default change detection.
And the reason is the same if an event occurred that naturally might have modified the data.
So we now need to check if some of the components need to be rendered in response to it.
We can see why on pushing detection mechanism will result in a better performance than default change
detection.
With default change detection.
We are checking all the expressions of all the templates in the component hierarchy.
Every time that there is an event anywhere on the application, we have to do that because we are not
given any guarantees that that event unapparent component might have modified data, which is important
for a child component.
So we have to check everything, all the expressions of all the components.
This also means that we need to keep in memory the values of the expressions that were calculated on
the previous change detection run.
On the other hand, with on push, if we know that the inputs of a given branch of the componentry have
not changed, then we can skip the whole branch entirely.
So if these Kirker component would have child components, those child components would not be checked
for change detection if the Corsair component did not have itself some changes to it.
So a whole branch of the componentry gets bypassed.
Also, in the case of the input data, such as, for example, JavaScript objects such as the coarse
object, we are comparing the data that gets passed by object reference.
So the comparison the.
Self is much faster when using on push.
We need to make sure that we don't mutate the object data that gets passed to a component when we are
using on push change detection, we have to make sure that the data that we pass is an input to a component
does not get mutated directly by other components, such as, for example, the parent component.
The best way to avoid this situation is to use immutable objects.
As we can see, unposed change detection is effectively faster, but it's also a bit trickier to use.
Let's not continue to delve deeper into the angular on pushing detection mode.
Let's not talk about how to handle observable data streams with unposed.