The killer feature of Angular 2

In some circles Javascript has a reputation as a kids language with a capacity to create horrendous unmaintainable spaghetti code. The next version of Javascript ES6 goes a long way to addressing that with much stronger object orientation standards, and in the last few years, many issues have been addressed. Supporting frameworks such as Ember, Angular, Typescript, Cordova, Coffeescript have all contributed to a maturing of Javascript. One thing is clear, Javascript is far closer to achieving the dream Java chased of a single language that works on all platforms.

I recently worked with one of our junior developers to refactor some code. The code in question creates live charts. The refactored code was 60% smaller. We took all of the logic out of the rendering modules and moved it to re-usable data preparation services.

Sentiments

Separating logic and presentation layers makes code easier to read, it also makes it faster, slimmer and easier to build on. This simple principle is one of the cornerstones of AngularJS

The Challenge, the solution and the cost:

The challenge is how do we separate / abstract the data controllers and presentation layers. The solution Angular offers is data-binding. With full data-binding we can create a data layer and a separate presentation layer. We can structure our code in such a way that it focusses the controller logic on manipulating the data, whilst leaving the presentation layer to update itself.

In practice this means that we can place all our attention on updating the data. We can create complex data objects with dynamic computations and focus on keeping our data structures updated, whilst data-binding means that our presentation layer updates itself. This approach works incredibly well and is a one of Angular’s great features, but it does have a problem.

The problem is that with large complex objects and arrays, or even arrays of objects containing arrays, how does the presentation layer know when a particular piece of data has changed.

Let’s look at a typical example. Imagine you are working on a platform and you realize your name is misspelled. Instead of seeing Veronica you see Veronicca in the header bar. Once you have been to your profile and updated your name, you expect the header to update and show your corrected name. Angular data binding will do this, but in the Angular 1 this was done by running a digest cycle that checked whether data had changed on each cycle. Once we have a lot of data, the processor cost of making sure your name is updated correctly becomes very expensive in terms of CPU usage.

The Angular 2 solution is a complete revamp of the way data is observed and by massively increasing performance it opens up huge possibilities for the complexity and amount of data we can automatically bind to our display.

The down and dirty technical is below:

Angular maintains a tree of “change detectors”, one per component/directive. The change detectors are created when Angular creates components and keep track of the state of all bindings.

Compared to Angular 1, the change detection graph is a directed tree and does not have cycles, and this makes Angular 2 much faster.

When an event fires, the event handler callback can update whatever data it wants to — the shared application model/state and/or the component’s view state. After that, the hooks then run Angular’s change detection algorithm. Every component in the tree is examined from the top, in depth-first order. For any binding changes that are found, the Components are updated. The browser reacts to the DOM changes and accordingly changes the display.

In summary the killer feature of Angular 2 is speed. With more speed we can create more powerful apps, and with increased performance we can realize the true potential of full data-binding.

Jon Anthony is Founding Director at Technology Partners http://www.adappt.co.uk