Angular 2.0 has been on everyone’s lips for a while now. So I finally decided to take a plunge and start digging into it. As of now I wouldn’t dare to call myself an expert, yet I would like to share my views on the matter, based on what I have learn’t till now.

As per convention, you would tend to think that it is probably an update over the last Angular version (1.5), but that would be wrong, Angular 2.0 is a complete rewrite of the entire framework.

But why would a framework, as popular as Angular need to be rewritten? Since its inception, Angular not only witnessed phenomenal growth in terms of adoption, but also gathered a huge community support, then why rewrite it, why Angular 2.0?

This is the primary concern that I would address in this series of blog posts about Angular 2.

In this blog post, we would talk about one of the motivations behind Angular 2, the enhanced modularity over Angular 1.x.

Enhanced Modularity

Gone are the controllers, the scope is dead, the DDO is not to be found, it’s absolute mayhem, OR is it?

Angular 2 seems to have been developed picking the best of all while overcoming the shortcomings of the existing frameworks at the same time. Everything is now component driven (similar to ReactJS). The core team has dropped the Controllers and introduced Components, which can pretty much provide the same functionalities, and much more, and much better.

First let’s try to understand the problem with controllers (and scopes).

In a basic Angular application, a view is nothing but a composition of directives. These directives should ideally be written as single, specific sets of encapsulated code, including the HTML (View) and JavaScript (Controller) responsible for carrying out a designated behavior, which can be reused across the application.

Then we have services capsuling all the business logic, leaving controllers mostly for user input handling and attending to the scope.

The best practices state that the controller should be kept as lean as possible.

Now, we all have been so used to structure the code on MVC pattern that when we start with Angular, the role of controllers seems well established. It is an arbitrator between models and views as well as the first receiver of a user action.

But are they really?

Every controller is paired with an object called scope which is intently responsible for all interactions with the view. And, if we have such an object in place, then controllers no longer remain the first receivers of user actions. Scopes do.

Then we have directives too, which in most cases can be used interchangeably with the controllers leaving the distribution of code to the coder’s discretion. In fact, we could very well do without the ng-controllers by modularizing our view with just the directives (of course they could have their own controllers).

Not just that, a few other problematic aspects bundle along with controllers.

For instance, each scope created by the controller prototypically inherits from the parent scope and understanding the effects of scope inheritance on your bindings could be a little tricky sometimes. And this is the reason why in the beginning most people run into common issues before they are told about ‘the dot rule’.

But that’s not the only problem that rampant scope inheritance causes. I am talking about the data sharing ways here.

The data and behavior assigned to one scope object is conveniently accessible by all nested ng-controllers and their respective scopes. Well, I do not mean to say that inheritance is a bad thing to have, but in a deeply nested structure one might get lost in complexity of data flow such as source of data, branching of the its subsets, its consumers etc.. making the system more fragile. This demands a refactoring at all places it is being used in case you need to change the structure of the data or even rename it. Not to forget the nightmares that comes along with running all the test suites all over again.

A few directives like ng-repeat use inheritance too. And I am sure that I am not the only one here who has been baffled by these scoping issues more than just once. Exemplifying one such issue:

This seems to be a fairly simple example and quite a common scenario as well, where I want to show a list of users using ng-repeat directive and on the click event of those items, the selected user should be displayed on the top.

If only it was this simple!

Angular’s ng-repeat directive stems out a new scope for every row. When I click on a row, it assigns the property selectedUser to the nested scope and chosen user would never show up on the top level scope leaving this example to never work out.

After beating my brains out while constantly digging in the stackoverflow pages I could manage to find a workaround for this problem. “$parent”

And if you have a complex nesting in your template then u might have to face a $parent.$parent.$parent …. chain. Not a pretty code I would say. And you might get some really judgemental looks by coding standards Nazis too.

There might be other workarounds as well for this scenario, but such a basic thing should be handled out of the box by the framework.

Well, the good news is that in Angular 2, the responsibility of execution context and the management of watchers are split up into directives, and we no longer need $parent . And as they promise, there are going to be no such surprises in Angular 2.0. 🙂

Angular 2.0 settles on moving user input handling to the directives instead of controllers. With a few levels of abstraction coupled with coherently created directives, you can ensure modularity, re-usability as well as separation of concerns. Along with the directives, the services, providers and dependency injections remain to play their characters.

Apart from this, various modules have been removed from Angular’s core therefore resulting in better performance. This move also aims to achieve more flexibility by allowing the developers more freedom to cherry pick the libraries/packages best catering to their needs.

When we think more about the controllers and templates in Angular 1.x, controllers turn out to be half baked components anyways, which are basically directives in Angular 2.

Like really! Does that mean that I will have to write only what I dreaded the most? “The Directives”?

Well, yes firstly. But the good part is, it’s not that dreadful anymore as Directive Definition Object (DDO) is dead too. Happily RIP 🙂

The new directives are simply ECMA6 classes with an annotation specifying them as a directive. This move would definitely allure a lot of back-end developers to start writing client-side code by bridging the gaps. Which means, all the methods and the properties are present in the class which can be directly bound with the template without being mediated by any complex object.

Now that the components give you a full execution context to the template, who needs a special scope object anymore?

Yep, you got that right. The scope has passed away too.

But who said the scope was only to give your template an execution context. What about the additional responsibilities it used to carry…like adding watches, and there was also an event system to it. In Angular 2, they have split up all of these responsibilities into 3 different type of directives, thus making things a lot simpler.

These three types covers all the scenarios when people need directives.

  1. The components replacing the controllers are actually the isolate scope directives called the Component Directives, coupling behaviour with their own templates.
  2. Then there are Template Directives like ng-repeat or  ng-if , which affect the element structure directly.
  3. And lastly, we have Decorative Directives like ng-class , ng-show , ng-hide  which only affects the attributes of the elements.

All three have different annotations so that you can get a head start while writing your directives.

In this way, the components that you write in Angular 2 would be self-sustained, fully functional modules that could be pulled in any root template as APIs, bringing the design closer to the modern day Web Components like the Shadow DOM. I feel this opens up possibilities for further modularity like bundling each component with its own CSS. .

Now, this is what I call modularity redefined. 🙂

As a side note, there is another thing worth discussing.

So before when u wanted to use a directive, you would just register it once with the application and use it anywhere in the application.

In Angular 2, you need to explicitly specify the directive you want to use in a particular template, allowing us to do better validations and unit testings, making it as optimizable as it was never before.

Yes! I agree it’s more work but later while working on it you would thank Angular 2 for thinking about it, as it would save you from the collision issues that you may run into with Angular 1.x, especially when you use 3rd party components with their own dependencies that you would not know about.

By now, do you like Angular 1 or do you like Angular 2!

So, to conclude my line of observations about modularity, controllers, components and directives:

  • We don’t need controllers anymore as we are embracing the Component Model.
  • We don’t have DDO, but in its place we have annotations for 3 different kinds of directives.
  • We don’t have the $scope too because the execution context of our template now, is the Component itself.
  • We can use the DI query mechanism if we want to communicate to any of the child components but that explanation is out of scope of this discussion.
  • Angular.Module is killed too as we are all set to exploit the inherent module loader of ECMA6.
  • For performance optimizations, we don’t need JqLite too.

In the next few posts, I will discuss about targeting typescript, mobile development, leveraging shadow DOM, unidirectional data flow, type checking enabling etc.

Stay Tuned…