Hello, everyone, and welcome back.
In this lesson, we're going to talk about system change detection, as we have seen before, and Google
provides us with two mechanisms that work out of the box.
We have the default angular change detection mode and we have also on Pushkin's detection that we have
covered in previous lessons.
As we have seen these two modes of change detection work in a very different way.
The default change detection mechanism is going to base itself on the values of the expressions in the
template.
It's going to compare the current value with the previous value to see if a change occurred.
If that's the case, then the component gets marked for rendering.
On the other hand, with on push, we are pushing the data explicitly to the template.
So we are pushing the data either via input properties or via the async pipe into the component.
The component will know then that it needs to shake if some new data is available and decide if the
view should be rendered.
In both cases, if an event occurs because an event can implicitly modify the data in both situations,
we are going to be checking the component to see if it needs to be rendered.
These to change detection models will cover the vast majority of various cases.
But there could be some particular situation where you need to inform Angular manually that change detection
should be executed for a given component that is possible.
Also, let's give here a concrete example where that might come in handy.
Let's switch here to our application component and let's leave it running here using on push change
detection.
Now, what we are going to do is we are going to switch here to our template and we are going to again
remove here the use of the async pipe.
So instead of providing an observable to the template unsubscribing to it using the async pipe, let's
just define here.
A course is synchronous member variable.
So this will be an array of courses.
Now, instead of assigning here to these observable variable, we are going to call the back and we're
going to subscribe to these observable.
We are going to take the courses that we get from the backend and we are going to assign it here to
the courses member variable.
And notice that because we are using here on push change detection, if we try this out, we are going
to see that there is no data on the screen.
And this is because there is no way for this component to know that it needs to be rendered.
We did not pass the data via a pipe to the template and we did not provide the data via a component
input either.
So there is really here no way for this component to know that it needs to be rendered.
However, if we would like to manually inform Angular that whenever some data arrives here from the
backend, that in that case we would like to mark the component for a change detection check, then
in that case we can do so using the component change detector.
So every component in ANGULAR has its own change detector that can be injected using the change the
ref angular injectable.
So this is the change detector of this particular application component and every component has its
own change detector.
So the change detector of our application component is going to be different than the change detector
here that we could inject also in the course Kerith components.
Let's then see how can we use the change detector ref to manually inform Angular that it needs to check
these components.
So we are going to check the API available in our change detector.
We have here several functions and if we scroll down the list, we are going to find this function mark
for shick.
So these will inform Angular that this component should be checked for changes.
Now, if we tried this out, we are going to see that this time around.
Indeed, the data is getting correctly reflected on the screen.
These functionality, the use of change detector Şeref should not be used systematically.
Instead, we should rely on either the default change detection mechanism or on Bush in order to check
our components.
This is just for a very exceptional situations.
Let's give a concrete example.
Let's say that, for example, you are continuously pulling the backend for more data and that you are
receiving data very frequently.
Let's say that you are receiving new data several times a second.
Well, in that case, you might not want to push the data continuously to the user interface because
that could cause performance problems.
Instead, you might want to wait for one second or two before pushing new data into our user interface.
So for that, it would be a matter of calling here.
The change detector mark for check function once per second instead of every time that we receive a
new value from the backend.
That is just one example.
Now, let's see another way of implementing here the same functionality.
Instead of calling here the mark for check function directly in our subscribed call, we can alternatively
implement here another interface.
We.
She's the do check interface, so this is a life-cycle hook and we are going to cover all the life cycle
hooks available in the moment.
Right now we want to implement these methods.
Engie do check.
So this method is going to get called every time that is running change detection in a given component.
So if you want to do custom change detection, this is the right life hook to use.
Let's remove here this call to the change detector and let's move it here inside engy to check.
So if we try these out, we are going to see that every time that we are receiving some new data from
the backend, the data is getting correctly displayed on the screen for comment about this call to Mark
for check, then no data is getting displayed because the component does not know that it needs to be
rendered.
These Metford Engie Do Check is the best place to implement some custom change detection logic.
Let's say that we would like to implement here some very specific change detection logic that would
render the component, but only the first time that some data gets back from the backend.
So if the observable would be mid-year further values, those would not get reflected here on the screen
could implement that in the following way.
We can add here and if close and we can check if the course is variable is defined or not.
Initially this variable is going to be undefined, but if it already has a value, it means that the
value has already arrived from the backend.
So in that case, we are going to call the first time the change detected.
Let's also add here some logging so that we can see what is going on.
We are going to log here to the console, simply the name of the lifecycle hook, these life-cycle hook
and the check is called very often.
So if we now check here in our console, we are going to see that we have here a series of calls to
engy do check.
Now, each time that this method is called, in case the variable is already defined, we are again
marking the component for being checked by the angular change detection mechanism.
If we would like to do this, check only the first time that we get some data from the back and we could,
for example, add here an extra flag so we could define here a loaded boolean flag that we are going
to initialize to false.
We are then going to set this flag here to true whenever we get some data from the back end.
Now we are going to take this flag and we are going to use it here in our custom change detection logic.
So we are only going to mark the component for check if the data is already loaded and this will trigger
here change detection in this component for the first time.
Now, the next few times we would like to avoid calling here, Mark, for check because we are sure
that we will no longer receive here any data from the back end.
So in order to ensure that we are going to set this flag back to undefined, let's add here some extra
logging so that we see what is going on.
Whenever the code reaches this point, we are going to look to the console called KDDI Dot marked for
Shick.
Let's check in the console.
What is the final result?
So first of all, we can see that after reloading the application we have here, the data correctly
displayed on the screen.
And notice here in the console, engie to check is being called a bunch of times.
We have here already free calls.
And if we click here, for example, the edit course button, we have here a fourth call.
So this method is being called many times after each browser event.
This is going to get triggered.
But the cold change detector mark for check function is only being called once.
So as you can see, we can use the API of the change detector ref to implement our own custom change
detection logic.
This should only be used in very special cases where we want to do some type of performance optimization.
Again, in the vast majority of cases, default change detection is going to work great and if we really
need on push, change, detection should solve all the performance problems that we encountered.
If we fall in a very specific case where you need something more than that, then we can always resort
to using the change detector reference.
This should only be used as a last resort.
For example, here in this implementation, it would be much easier to simply use the async pipe here
at the level of the application component and have the on pushing detection mechanism detect the changes
automatically for us.
And we d we have covered the multiple mechanisms that we have available for performing change detection.
Now what we're going to talk about is the angular lifecycle hooks.
Let's talk about in detail about all these lifecycle hooks that we have seen so far, such as energy
need energy to check.
Let's talk about the order point, which they're called and the typical use cases where we will need
them before going any further.
Let's do a bit of cleanup.
Let's remove here to the implementation of the check.
We don't need unperceived.
Detection anymore in our application so we can remove these can also remove here the change detector
reference and let's remove here the implementation of the lower the flag.
And with this small cleanup in place, let's not start a new section of the course.
Let's start our deep dive into the multiple angular lifecycle hooks.