Introduction

Angular 2 is bringing sweeping changes to the method of web application development. Hence, I am hard-pressed to add another feather to my blog about change detection(CD).

“The crux of a plethora of front end frameworks is change detection or in layman terms, projecting the data/model onto the view (not necessarily HTML but any view) as it changes and vice-versa without the mind-numbing tedious verbose boilerplate code”.

This has been the challenge for the community and angular 2 to a certain extent has solved this. Though there are other frameworks that tackle it better but with tradeoffs. The article makes some assumptions that the reader has prior knowledge about the JS, Angular 1 & 2(especially componentizing the application), two-way data-binding & also how change detection has evolved from angular 1 to 2 (beginner level). Like always- we are not what we are if we fail to tackle insuperable challenges.

Harbinger of Change

MVC pattern inherently brings in a model and a view, this view is typically a UI (DOM HTML). When the model is mutated or modified, this change must be detected and pushed or propagated to the view. On any given UI there can be multiple UI elements and hence multiple repetitive code snippets, which can be tedious and hence that’s when angular 1 and 2 as well, hunched this idea of taking the onus of conventional routine code which are routine updates from model to view and vice versa as well, and pre-bake that verbose code into the framework. This allows the user to focus on the business aspect of the application.

Tree of Components

The HTML DOM is by nature a tree, and within that tree, one could group elements (like branches and sub-branches) and the business logic associated with those groups of elements into components. This I believe gives an edge to Angular 2. Why? Back in Angular 1 we had similar pattern like templates (group of elements) and associated controller but the change detectors were spread across the whole tree as monolithic entity and there is by no means in legacy Angular 1 to control the cycles of detection and for every mutation in model or UI, we must brute force the change detectors to run on every node elements which are observed or watched for change. This is not an optimal solution. Just imagine one change at leaf level causing it to fire a burst of cycles of check and sometimes it gets worst by running circular cycles until it gets stabilized and all the updates are finished (which can be infinite and unmanageable occasionally). Now let’s talk about the edge-each component takes an isolated ChangeDetectorRef object; which controls the change detection strategy for that component alone. You can plug or attach and unplug or detach the change detector code during runtime and compile time (using ChangeDetector.OnPush option)-giving more power. But with more power comes more responsibility of calling MarckForCheck() method that manually propagates the changes to the concerned view.

Change detector or $watch method- What does it really mean in JS world?

It is a function that takes in the old and new value parameters of the model property that is being observed and in that function body it compares using IF operator and if they are same it skips otherwise (mutation has happed) it kicks in the brute force change detector cycle or sequence. Just visualize every element that is observed for changes automatically tied or attached to function. Also, the change detector cycle is kicked in during the async event like click (ngClick) too. But for the sake of simplicity let’s stick to model mutations and if time and space permits we can dig in.

Conclusion

Componentizing the application into meaningful smart chunks can eventually be leveraged in applying the change detection on exclusive branches/sub-branches and eliminating brute force cycles, which limits the performance of the application and browser as well. Moreover, unlike angular 1, angular 2 is top-down change detection orientation, this holds true even for changes at leaf level.