Angular is one of the most extraordinary javascript frameworks available, because it all the features required for the web development out of the box. The change detection system is at heart of framework, it essentially helps to update bindings on a page. In this article, we will learn about change detection in detail, in a simple and easy to understand way.

Before we begin, let me highlight what principles frameworks or libraries to build applications these days.

General Application Architecture

Basically what we have is the state of our application, that we are trying to replicate on the UI, this is why we need data bindings on the template. Afterward we wire up “state + template” and replicate data on view. Also in the future, any changes that happen in the state get reflected on view.

This process of syncing HTML with the state can be termed as “Change detection”, each framework has its own way of doing it. React uses virtual DOM with reconciliation algorithm, Angular uses change detection, etc. This article will cover how change detection works in Angular.

What is Change Detection?

In simple word:- a process to synchronize the model/state changes to the view.

Let’s take a simple example. Suppose we have a simple component with its own HTML like shown below.

<span>
{{title}}
</span>
<button (click)="title='Changed'">
Change Title
</button>

<span>
{{title}}
</span>
<button (click)="title='Changed'">
Change Title
</button>

app.component.html has a simple app.component.html which is displaying the app.component.html property of a component and there is a app.component.html on click which will modify the app.component.html property value of app.component.html.

demo

When the page gets happens, it shows "app.component.html“ on the page. Later when we click on Change Titleapp.component.html it changes the binding value to ”app.component.html“. This is super awesome, the Angular framework manages this functionality for us. What it essentially does is, track the value changes which are automagically reflected on the UI. Awesome! Check this stackblitz of the above example.

Wondering 🤔 How angular updates the binding? That’s okay! Nothing really happens with magic, a framework must be running some code behind the scenes to do it. This process of updating binding is called as change detection. But the question is when angular running a change detection and how? To find out answers to these question, let’s dig a bit further.

When should change detection happen?

The simple answer to this question would be “as soon as an application’s state changes”. But when does the application’s state can change? 🤔

1. Event Callback
2. Network Call (XHR)
3. Timers (setTimeout, setInterval)

Do you see any similarity in the examples above? Yes! they are all asynchronous. That means we can simply say any asynchronous call can cause a change in application state and that’s the instance where we should update our state on UI. So far so good!

Suppose we’re building our own change detection system, we would be firing change detection after the above 3 situations.

Let’s try to implement our own change detection system.

We’re just making sure to call app.component.html method from each method which includes XHR call, Timer, and Event. Just assume that the app.component.html method is responsible for the actual change detection. The vague implementation of change detection would look like the example below

<span>
{{title}}
</span>
<button (click)="title='Changed'">
Change Title
</button>

And the implementation of app.component.html method would look like the example below

<span>
{{title}}
</span>
<button (click)="title='Changed'">
Change Title
</button>

Ah! but doing this thing inside our real-world application will mess up everything. Generally in a real-world application you could have this in hundreds of thousands of places. So what can be a better implementation of this? Basically, we can also say that we are supposed to fire change detection when VM turn is over.

ZoneJS to the rescue

ZoneJS is an API which has been mostly ported out from the dart language. Behind the scenes, ZoneJS monkey patches the function. Basically, it helps to keep an eye on all async tasks, and provide an ability to call code before or after a task has been completed. The Zone API has different hooks to place your code app.component.html, app.component.html, app.component.html, app.component.html.

<span>
{{title}}
</span>
<button (click)="title='Changed'">
Change Title
</button>

So Angular uses the power of Zones to fire change detection. What happens is, if any asynchronous call happens, ZoneJS API emits data to the app.component.html observable, and angular calls the app.component.html method based on the same.

What happens when Application Bootstrap?

When an angular application bootstraps, it creates a platform for a bootstrapped angular module. It creates an ApplicationRef for a whole module. Basically, app.component.html has a reference to allapp.component.html, app.component.html and app.component.html (zone flag), also it has methods like app.component.html , app.component.html , app.component.html etc. You can look at this line from the source code.

Let’s have a quick look at application_ref.ts from the angular source code. You will see that after creating an app.component.html , it places a subscription on the app.component.html observable, so as soon as the VM tick over it emits a value into app.component.html observable, that will be listened to by a subscription, eventually that will call the app.component.html method inside the current Zone of application.

<span>
{{title}}
</span>
<button (click)="title='Changed'">
Change Title
</button>

Let’s look into how the app.component.html method works.

<span>
{{title}}
</span>
<button (click)="title='Changed'">
Change Title
</button>

Implementation of the tick method looks pretty simple. It basically loops over each view (components are internally referred to as view) and calls their app.component.html method which is responsible for updating UI bindings. The interesting thing is on the 4th line, it runs only in dev mode because in the application_ref.ts constructor it sets toapp.component.html property.

app.component.html

Above is a gist about how change detection works, let’s dig deeper how we can use this while crafting Angular application.

Change Detection Strategy

In total angular has two flavours of change detection.

1. Default
2. OnPush

Let’s look at each change detection strategy.

Default

When you don’t specify the change detection strategy on the Component decorator, by default angular applies the app.component.html strategy.

Any Angular application consists of components, the component where we bootstraped a root component. and we can draw out a diagram of an application with regards to a component. So if change detection fires in any component it will cause the app.component.html method to be fired in the app.component.html . Ultimately firing app.component.html method from root component to its descendants as shown in the diagram below.

The problem with the default strategy is, changes that have been detected in on any component lead to firing change detection on all the components (if all component are set to app.component.html strategy. But most of the time we don’t need such behavior, it would eventually affect the performance of an application by running multiple unnecessary change detection cycle.

Can we solve this problem efficiently? Luckily there is a solution, you can easily switch the change detection strategy to app.component.html .

OnPush

app.component.html strategy makes component change detection bit smarter. It runs a change detection for a component only when app.component.html bindings value of a component is changed. Actually, it compares the reference between oldValue and newValue of a app.component.html binding. That means if a parent components properties of an object do not change it would not trigger change detection for that component. It’s recommended to use app.component.html strategy for all components, resulting in a significant amount of performance gain.

As you can see in the above diagram, we’ve set a level 1 component to app.component.html strategy. Both the component have the input of app.component.html . The root component is passing the input app.component.html to both the component with app.component.html and app.component.html respectively. On initial page load change detection fires on all the components. And later the right-hand side component emits an event, which tends to change the root component state.

So, again change detection started firing from the root component. Then change detection runs for the 1st level (app.component.html) component. Before firing change detection on those components, it checks for the input binding app.component.html newValue and oldValue and if there are changes then only fire change detection for that component and it’s descendants. Changes have been detected for the right-hand side component. So change detection gets triggered only for right-hand side branch of components. By setting app.component.html change detection strategy we can significantly improve application performance.

Make sure you enforce immutability on the app.component.html binding value while using component app.component.html strategy.
Before proceeding we can have a look at a real application that is built using both change detection strategies. This application is deployed on https://pankajparkar.github.io/demystifying-change-detection .

This is a pretty simple application, it has posts displayed on the page and each post can have comments. The way that the application architected, it’s component hierarchy shown below.

root => post-list (all posts)=> post (single post)=> comment-list

The black border around the component indicates the boundary of that particular component.

Since we want to keep eye on when change detection fires, we highlight the components to yellow as soon change detection fires. We have used app.component.html which tells us that the change detector has visited the current component.

<span>
{{title}}
</span>
<button (click)="title='Changed'">
Change Title
</button>

So you can see in the above diagram, on initial page load gets highlighted and they applied with app.component.html class. Thereafter while adding a comment in a comment field, you can see that on each app.component.html event it fires change detection and all component get highlighted.

Now, look at the uses of the app.component.html change detection strategy, how it makes a difference in the change detection run cycle.

Right now all the components are set to app.component.html strategy. So on page load change detection runs for all components, that’s perfectly fine. Thereafter when I tried to add a text in the comment section, it fires change detection for the comments section of the current component, not others. That’s great! But you can see that the other components post components are getting highlighted.

Ah! What is going on? PostComponent is already set to app.component.html , there is no app.component.html binding on that component but it seems to be changed. Is this a bug, is the ngAfterViewChecked lifecycle hook being called without reason? Perhaps.

Let’s not get confused. We can look into further.

Refer to the above diagram — When change detection is running for a parent component, it follows a certain process. Initially, it updates the binding of child components, then calls the app.component.html , app.component.html , app.component.html lifecycle hook of the child component. We can also state that this process happens before rendering the parent component. Then it updates the DOM on the current component. Later it runs change detection for a child component(depending on the strategy), followed by calling hooks app.component.html , app.component.html .

That means while running change detection of a parent component, it runs app.component.html, app.component.html, app.component.html lifecycle hooks of child component irrespective of a component change detection strategy.

Check this Github issue link logged by Pascal Precht ʕ•̫͡•ʔ

You might have missed, **There is a catch. **If you look at the change detection strategy of app.component.html, it has been set to app.component.html strategy, but there is no app.component.html binding passed to it. So when app.component.html component retrieves a data form the app.component.html hook, it doesn’t run change detection from the root component (app.component.html). But it prevents to running change detection on app.component.html since no app.component.html have been changed. So we had to call either the app.component.html method or the app.component.html method of app.component.html dependency. This will force change detection to run throughout. Such cases can easily happen in a real-world application. You can tackle such situations by calling app.component.html or app.component.html .

TL;DR

The difference between calling app.component.html , app.component.html and app.component.html would be

app.component.html — Once you call app.component.html method on component change detector, it will traverse a component tree till root, and mark those components to run change detection only for the next iteration. It will run change detection on marked component even though they are using theapp.component.html strategy.

app.component.html — When you call this method on app.component.html provider, it will run change detection from the current component and all it’s descendants. While running change detection it keeps the change detection strategy in mind.

app.component.html** — **The app.component.html method applicable on app.component.html API. It will run change detection from the root component to all its descendants. It respects the change detection strategy of a component.

There are two more methods that exist in the app.component.html provider

app.component.html** — **By calling this method you can pluck out a component from the tree of the current component to its descendants. Whenever there is a need for running change detection on the component you could call app.component.html or app.component.html method depends on your need.

app.component.html** — **A Plucked a component from the tree can be easily brought back to its original place by calling app.component.html method. This can be used for fine tune application performance.

I hope this article has helped you to understand the mystery of what’s under the hood of change detection. Eventually, this will also make you comfortable with predicting when change detection runs in your application. By applying various flavors you can easily gain performance benefits in your application.

#angular #javascript