Juri Strumpflohner

Juri is a full stack developer and tech lead with a special passion for the web and frontend development. He creates online videos for Egghead.io, writes articles on his blog and for tech magazines, occasionally speaks at conferences and holds training workshops.

Videos and runnable code samples to play around with change detection

I recently prepared some course material for a modern web development workshop, which besides the nice features around ES6 obviously also included Angular. Change detection was part of that workshop and so I did some playing with it. Here are some things that you should know.

Contents are based on Angular version >=2

I’m totally aware that there are already quite some good articles out there which go very deep into Angular’s change detection. Here are some I highly recommend to go through:

Change detection is the process of keeping both in sync. Basically when someone changes the name aPerson.name, the HTML part should reflect that change.
Such changes come in through asynchronous things that might happen, such as

Events (i.e. button clicks,..)

XHR requests (i.e. calls to some API)

timers (i.e. setTimeout, setInterval)

Ok, so someone has to monitor all these asynchronous activities. But how? Exactly! While AngularJS (v1.x) did something called “dirty checking”, Angular (2+) monkey patches all these asynchronous parts using zones.js. Again, more details can be found in the articles I linked before.

(Ok that hopefully was a minute or so? )

Tuning Change Detection

While it is extremely fast, what’s important to remember, is that change detection has a cost.

"Change Detection has a cost."

Angular applies some very smart techniques to reduce this cost at a maximum. But still, whenever we can, we might want to help it a bit further. And we have lots of options to do so.

In order to understand these strategies however, we need to know one thing first: the component tree.
As you might already know by now, every Angular application is structured as a tree of components. We have a top-level component, i.e. the <app-root>, which contains other components, which again contain other components and so on (you get the idea ). In the end what we get is a nice, directed graph without cycles: a tree.
Within this tree structure, data flows “downwards” through properties, declared via @Input and then back up from the child components to the parent component via events, using @Output.

Whenever one of our asynchronous activities kicks in, say in the <person> component, change detection is triggered from the root <app-root> to the bottom. As a result, change detection is triggered on all of our components. Well, by now you might guess that in a big component tree, with lots of components, potentially also doing quite some heavy stuff, this might get an intense computation.

When we speak about optimizing the change detection, we really mean to cut off edges of our component tree, which the change detection process otherwise would have to traverse, thus it gets faster. Frankly, it’s like saying, hey, wait, we only changed <person> and “I know” you don’t need to also verify <favorites-list> etc.

So here are some strategies you can apply.

Immutable Objects

Before speaking about immutable objects, let’s see what happens “normally”. So we have an object, say..

These steps alone won’t work however. Why? Well, we never change the reference of our Observable and since we still have ChangeDetectionStrategy.OnPush, Angular’s won’t execute change detection on this sub-tree. Thus we need to manually mark the changes.

As you can see, whenever we get a new value in our subscribe(..) we manually tell Angular to mark this sub-tree for change detection.

Manually handling change Detection

Well, if you’re still not satisfied, there’s one more option. You can even manually enable/disable change detection. This could turn out to be useful if you get lots and lots of data repeatedly from some backend and you want to perform change detection only every second or so.

In that case the ChangeDetectorRef has two interesting methods:

cd.detach()

cd.reattach()

Try it yourself in the runnable Plunker .

Conclusion

This is definitely part of the more advanced techniques when using Angular. But it is a powerful concept you should learn how to leverage to speed up your application even more.

I hope these runnable examples gave you some more insight (and starting point) into the power of change detection in Angular. Definitely also check out Pascal’s article as well as his talk on change detection at NGNL2016.