Hello, everyone, and welcome back.
In this lesson, we are going to continue to dive deeper into angular on pushing detection and see how
this change detection works with observable streams.
Now, in the previous example we were using here the courses file containing here's some data we were
applying here, the data directly on the template.
Let's now refactor this and fetch the data from the back end.
Again, this will give us an observable data stream.
We're going to pass it to the template and see how angular on pushchairs detection handles that.
So let's remove here.
This course is variable and let's define here.
The course is observable like before, which is an observable, of course, array, meaning that the
value emitted by these observable is an array of courses.
Now let's populate the courses variable here on engy on init.
We are going to assign the value returned here by the course service whenever we call the low with courses
function.
Now we want to display this data on the screen.
Let's for that first remove here the implementation of unpadded course because we are getting here a
compilation error and we are going to see how can we display this data on the screen.
Let's take the courses observable and let's use it here directly in the template.
So just like we have done before, we are going to apply here NGF and we are going to take the courses
observable and we are going to apply it to the async pipe.
We are going to take the result of evaluating this expression and we are going to define this as being
the courses local template variable.
Let's try this out.
If we were lower the application, we are going to see that again.
We have here our data working as expected.
Let's remember that in these implementation, we are using here normal change detection here at the
level of the application component.
Let's see if we would still get this list of courses on the screen, if we would use, for example,
on push change detection.
So if we try this out, we are going to see that we still have here the data being displayed correctly
on the screen.
This means that unposed change detection will look not only at the inputs of each component to determine
if something has changed and the component needs to be rendered.
But on pushchairs, detection will also look at any observable streams that are registered in the template
using the async pipe and see if a new value got emitted by the registered observable.
This means that with on push change detection, there are two ways to push data to a component, either
via input properties of the component or via observable streams via the async pipe.
Both ways of pushing data to the component will trigger the rendering of the component.
Let's now see what will happen in the case of push change detection if we would not be using here via
a sync pipe.
So let's see that instead of having here, this course is observable directly being passed to the template
that instead we will have here at course's member variable D member variable is of course, array.
So this is the variable that we are going to be passing to the template.
Now, instead of assigning this call to the courses observable, let's instead take the return, the
observable and we we're going to subscribe to it directly.
We are going to receive here the courses value each time that the observable emits a value.
And we are going to take this value and we are going to assign it to our new member variable courses.
So in order to avoid any confusion, let's comment out here.
The course is observable member variable.
So we have just refactor our components so that we don't have here and observable member variable.
Instead, we have a plain member variable.
It's just an array of courses and we're going to try to pass these to the component, just like we were
doing before.
So instead of using here the async pipe, we are simply going to come out this expression and we are
going to see that the courses member variable is already available here at the level of the component.
This means that if we try this out, we could expect to see the same result.
But let's see what happens.
So if we reload here, the application, we can see that we have no data getting filled in on the screen,
even though we are populating here, the courses member variable.
So what is going on here?
Why is the data not getting displayed this time around?
Well, the problem is that this component is using on push change detection.
Again, we fall into a situation where even though it's more performant to use on push, we run into
situations where the view does not display the data.
So we are going to comment out here on push change detection or you're going to see if this would work
with default change detection.
And indeed, it does work correctly.
So the way that default change detection works is every expression here on the template is going to
get evaluated, see if there were any changes.
This includes here the expression path to energy for which is the.
Racecourses, because whenever the data arrives from the weekend, we assign it here to the cast member
variable, we are going to do a switch of the value of these variable from undefined to a value containing
an array of courses that just arrived from the backend that is going to trigger change detection, which
means that the ANGULAR is going to render the template of this component.
And then we see the data on the screen again.
We can see the default change detection just works in the larger variety of scenarios without us having
to reason about the mechanism itself.
Let's not turn on on push again at the level of the application component.
So again, the data is gone.
What happens here is that the component is not getting notified in any way that it needs to be rendered.
So we on push that can happen in three different ways.
This could happen if an event would occur at the level of the application, either a DOM event that
we have registered using the angular template syntax or a custom event.
Another way that we could notify the application component that it needs to be rendered would be if
some input data has changed.
But this component here has no input member variables such as, for example, the cost curve component,
the first way that the application component could be notified that it needs to be updated when using
on Bush would be if unobservable registered with the sync pipe would trigger a new value.
And these observable here that we are using is not being passed to the template using the sync pipe.
So in summary, there is no way for the application component using unpunched change detection to know
that it needs to be rendered with on Bush.
We are no longer evaluating all the expressions here in the template.
Instead, we are pushing data to the component, either via inputs or via the async by.
So the component does not get updated in this case.
If we know refactor our implementation to use again the async pipe by removing here the call to subscribe
and then applying here the previous NGF expression with the use of the async pipe to the template.
Then this time around, after reloading the application, we are going to see that we get the data again
and that is because we are using the async pipe.
So in summary, if you were working with observable data streams and you are using on change detection
in some of your components, make sure to use the sync pipe as much as possible.
This is one of the multiple benefits of using the async pipe it makes on push that much easier to reason
about.
And of course, the sync by will also take care of and registering from any observables when the component
gets destroyed.
So there are many advantages for using the async pipe.
Let's now quickly summarize everything that we have learned about on push change detection.
As we have seen in these examples on change detection is faster.
It's more performance, but it's also trickier to use default.
Change detection just works.
We don't have to think about it.
It simply keeps the data in sync with the view at all times in a transparent way.
If by some reason you have to display a lot of data on the screen and you are running into performance
issues while doing so, then you might consider using on push to solve that problem if by some reason
you decide to use on push.
Here are a couple of important recommendations.
When working with observable data streams, use the sink pipe as much as possible.
This is going to reduce the number of cases that you will run into where the view is not getting updated
to reflect the latest changes in the data.
Also, if you are using on PUSH, it's important to avoid to mutate the data directly at the level of
the view, which is a good idea anyway, because it leads to programs that are easier to reason about.
So you could consider making your data objects immutable either by freezing them before passing them
to The View.
So this is standard JavaScript functionality.
You just make all the existing properties only.
Alternatively, you can consider using a library such as Immutable G.S. or IMOD for the vast majority
of use cases.
I would recommend to you to use default angular change detection and to not use on push.
But if you ever run into the need of using unpunched now you know how to do it.
Let's not talk about another performance optimization that we have available in ANGULAR.
It's the attribute decorator.