Angular Change Detection Strategy: An introduction
The way Angular performs its rendering and updates its views is a key factor on apprehending the framework’s internal system and basic features. Let’s just pause a few minutes and getting to know better the way Angular’s Change Detection Strategy is working.
First let’s be on the same page, what means “change detection” anyway?
The basic mechanism of the change detection is to perform checks against two states, one is the current state, the other is the new state. If one of this state is different of the other, then something has changed, meaning we need to update (or re-render) the view.
Change Detection means updating the view (DOM) when the data has changed.
Change Detection is done in two steps
Angular’s change detection is done in two steps, the first one is done by having the developer updating the application model. He can do it by changing the property of a component or emitting an event. Then Angular’s job will be to reflect the state of the model in the view, by re-rendering it. Usually this means that Angular will update by sending an event and/or by property bindings.
- Update the application model (developer);
- Reflect the state of the model in the view (Angular).
To be able to properly demonstrate the flow of Angular’s Change Detection, we need to take an example. In Angular, each application is a bunch of components glued together with some Inputs and Outputs to be able to propagate data and model states. Your application is basically composed of what we call a component tree.
If we take a todo application, represented by the graphic above. We have a fairly simple application that has a
TodosComponent managing a list of
TodoComponent. If we modify this list, by changing the value of the first item of the todos’ list (in yellow), we will have the following flow:
- The developer is making changes to the model (like a component’s bindings);
- Angular’s change detection kicks in to propagate the changes;
- Change detection goes through every components in the component tree (from top to bottom) to check if the model it depends on changed;
- If Yes, it will update the component;
- Angular updates the component’s view (DOM).
The way Angular runs the change detection by starting from the top and continuing until it reaches the bottom, makes the system more predictable and more performant.
Angular Change Detection Strategies
Angular provides you two Change Detection Strategies, the default one and the onPush.
In order to know whether the view should be updated, Angular needs to access the new value, compare it with the old one, and make the decision on whether the view should be updated.
By default, Angular makes no assumption on what the component depends upon. So it has to be conservative and will checks every time something may have changed, this is called dirty checking. In a more concrete way, it will perform checks for each browser events, timers, XHRs and promises.
This can be problematic when you’re starting to have a big application with many components, specially if you’re focused on performance.
By default, Angular has to be conservative and will checks every time something may have changed, this is called dirty checking.
When using the
onPush strategy on the component, you basically say to Angular that it should not make any guess on when it needs to perform the check for change. It will rely only on the change of the Input references, some events triggered by itself (the component) or one of its children. Lastly, you, the developer, can ask explicitly Angular to do it with the
onPush, the component only depends on its inputs and embraces the immutability, the change detection strategy will kicks in when:
- The Input reference changes;
- An event originated from the component or one of its children;
- Run change detection explicitly (
- Use the async pipe in the view.
With onPush, Angular will only depend on the component’s inputs, events, markForCheck method, or the use of the async pipe in the template, to perform a change detection mechanism and update the view.
This has for effect to gain a lot on performance, Angular doesn’t do any guess or useless work. It makes your application embrace the immutability, via its components.
If you want to go deeper in the subject, there are some really well written and interesting posts about this subjects. I recommend:
Exploring the underlying implementation and use casesblog.angularindepth.com
In this article I will talk in depth about the Angular 2 change detection system.vsavkin.com
Victor Savkin is a co-founder of nrwl.io. He was previously on the Angular core team at Google, and built the…blog.nrwl.io