What will happen now?

Regular development of 1.7 will continue, meaning we can expect 1.7.1, 1.7.2, etc. until June 30, 2018. All these releases will contain bug fixes and features that are not breaking changes.

What will happen next?

After June 30, AngularJS 1.7 will go into Long Term Support. This means that for 3 years the Angular team will support AngularJS and make changes to make sure it continues functioning. There will be no new features. Bug fixes will only be released in case a security flaw is found, or if a change to jQuery or a major browser breaks 1.7.

Why now?

Google say that in October 2017 the number of active Angular (that is, 2+) developers has surpassed that of AngularJS developers, which was their cue all along to when they can start wrapping up 1.x.

What should you do now?

If you’re still running 1.x, I highly recommend taking the time and moving to 1.6 (see my Modern AngularJS Migration Guide).

1.7 will be released soon, but it will also remove lots of deprecated APIs, meaning you can expect to need to change older code and update older dependencies.

And then what?

Hmm. That’s a tough one. I’ll be talking about it some more in the upcoming future, so make sure the sign up below!

Usually, I just add console.log as necessary, or add breakpoints. But, sometimes, I want to look at data as it currently is, without triggering a refresh.

In those situations, I love using AngularJS’s helpers that make a lot of the needed information available right in the browser’s console.

Set up

First, pick the relevant element in Chrome/Safari’s developer tools – either right-click and “Inspect Element”, or pick it on the elements panel.

On these browsers (maybe others as well, but I rarely develop on them), the element you have currently selected is available in the console using the $0 variable.

And now, you can get access to the AngularJS element by writing angular.elemen($0).

While you may know this as the jqLite interface, it has some handy utilities for debugging.

Debugging with angular.element

.scope()

This function returns the Scope that’s associated with this element. Super handy for poking around to see that all the values are set up as you expect. You can also make changes to values on the scope, or call functions, but in those scenarios it’s recommended to follow up by running angular.element($0).scope().$apply(), to make sure your changes are properly applied.

A nitpick detail is that in some cases you might want to call .isolateScope() instead, see the docs.

.controller()

Similarly, this returns the controller that’s associated with the current element. In the rare case that an element has multiple controllers and you’re interested in a specific one, e.g. ngModel, you can pass the function the name of the controller that you want.

Now with components, where you should be rarely exposing data directly on the scope, accessing the controller is nice, though this is usually synonym with angular.element($0).scope().$ctrl.

.injector()

This is especially handy for the heavier debugging sessions, where you’re knee-deep in chaos.

In those scenarios, sometimes you need to resort to calling all sorts of services on your own directly from the console, and injector enables just that.

For example, if your app has a UsersService, you can get a reference to it using angular.element($0).injector().get('UsersService').

Happy debugging!

And at the early stages of a project, especially before going live, it’s relatively easy and fun to always be using the latest shiny.

But, eventually you come across a problem. Simply updating some dependency has caused an issue that may just have cost you some time debugging, and at worst has caused a major issue that was only found out some time later. Once these happen once or twice, I see my clients go from trigger-happy-update-hippies to get-off-my-lawn only-update-if-absolutely-necessary-sceptics.

And, frankly, it’s hard to blame them.

Especially after a few too many times of playing whack-a-mole with issues that surface because of an update, and later realizing that had you just waited a month or so, most of these issues would already be gone (e.g. because they would get fixed, or because other people would have already tackled them on Stack Overflow).

But once you go into the never-upgrade camp, you’re setting yourself up for issues later on again. For example, eventually one of your dependencies will have an important fix/feature that you want now, but upgrading it requires upgrading other dependencies. But, since things have been left stale, you have to sift through so many breaking changes of dependencies, and that’s if you’re lucky and the dependencies have proper documentation.

For example, I recently saw a client that needed a simple update to their e2e testing framework require upgrading 8 more direct dependencies, some as major as “oh, we need to upgrade a major Node version for this and update our CI chain with it”. Ain’t nobody got time for that!

The Just-Right Upgrade Path

The pragmatic solution, maybe obvious at this point, is to have a process for upgrading gradually and with a schedule. If you’re in it for the long game, and plan on supporting your product for years on, you have to get some recurring task that reminds you to go over your dependencies and see which have updates that are, say, a month old.

Go over those, read their changelogs, make the changes necessary to upgrade and test things in isolation.

Yeah, it’s a hassle to do this in an ongoing fashion, but from my experience it’s always easier than dragging it out until the absolute last minute, when you’ve already got balls to the wall.

For example, Twitter’s current UI whenever you click a tweet’s timestamp, that tweet is displayed as a modal on top of the current page you’re on:

And from that screen you can stack up even more modals, e.g. by clicking to view who liked or retweeted that tweet.

Managing all those modals can be a PITA. You have to make sure clicking a link that goes someplace else dismisses all the modals that should be dismissed. And on the other hand, you have to make sure that dismissing the modal, e.g. by clicking that X button, results in the state changing together.

I’ve often seen this result in lots of copy-pasted code for handling dismissals and listening for state changes to clear things up. (Actually, while playing around with Twitter to get the screenshot for this post I noticed that simply clicking through some modals breaks things in twitter such as history in some of the cases…)

But, it doesn’t have to be this hairy and buggy. You don’t have to keep adding more and more checks for removing your modals everywhere in the hopes of it actually sticking. With the right design decisions, modals can work almost as seamlessly as regular bindings in AngularJS.

Reliable Modals

A reliable pattern that I’ve seen successfully implemented at several clients is to bind modals to a matching router state.
There are different ways this can be done, but the important issue is accepting the idiom that modals shouldn’t ever cross state changes – if a state is left, the modals it introduced should be cleared. Let the new state start fresh and clean of the previous thing.

The simple way – auto dismissals

This is by far the simplest way to make sure modals never stick around, and it works for apps with simple modal use. I’ve seen this working for years at several places and reliably. Essentially, you register a state change listener in your router and whenever there’s a state change you make sure to dismiss all open modals, whatever those might be. Again, this might seem harsh, but in some apps this works like a charm, and is better than nothing.

A simple example, using UI Router’s $transition service and Angular UI Bootstrap’s $uibModalStack, this can be as simple as:

1
2
3

$transitions.onFinish({}, function(transition) {
  $uibModalStack.dismissAll();
});

And of course, if needed, you can only perform this for transitions that match a specific criteria.

Hard binding modals and states

The hard binding solution is also the harder way, but it provides more flexibility and control. In this pattern, we configure the different states so that whenever a state is opened, a specific modal is initialized. Whenever that state is transitioned from, that same specific modal is dismissed. And, lastly, we make sure that if the modal is dismissed (e.g. by clicking a little ‘X’) the state itself is transition out from, usually by going to its parent state.

For example, the tweet details modals from the screenshot above might be defined like this state:

1
2
3
4
5
6
7
8
9
10
11

$stateProvider.state('profile.tweet', {
  url: '/tweet/:tweetId',
  onEnter: function($uibModal) { // 1
    $uibModal.open(...).finally(function() { // 3
      $state.go('^');
    });
  },
  onExit: function() { // 2
    // dismiss modal
  }
});

Breaking this down, first look at the line marked with 1. onEnter is called as the state is initialized, and then we immediately open up the modal that is bound to this state.

Similarly, on line 2, we make sure to use onExit to be notified of when the state is transitioned from and dismiss the modal in case it’s still there.

Finally, on line 3, we make absolutely sure that any dismissal of the modal, for any reason, will also result in a transition to a proper state. We do that by adding a finally callback to the modal’s dismissal promise.

This boils down to manually wiring two-way binding between the state and the modal, and it achieves air-tight confidence in your modals playing along nicely.

I compiled here the common patterns and anti-patterns, sorted and listed from you-should-probably-use-this all the way to please-god-no.

Always use when possible

Bindings

Bindings essentially mean passing a callback function a child component so it can call back on the parent. Use this whenever a child needs to pass information to its direct parent, e.g. a button was clicked or an error occurred.

$onChanges

The $onChanges lifecycle hook, which I covered here, coupled with one-way data flow, can be used as the opposite of callback bindings. By supplying a one-way binding (<) to a child component, the parent can essentially trigger behavior in the child by overriding the binding value with a new one, causing the child’s $onChanges to be called. Then, the child component can see which binding has changed and to which value, and act accordingly.

Use with care

Having to use these might mean that you’re doing something a bit too complicated, but not always.

Require

The require mechanism is strong and provides a lot of power, as described here and here. It can really simplify complex component families. And yet, don’t be trigger-happy about using it, since it also adds complexity.

Add a service with extra state

This actually has been the go-to solution for most non-obvious communication patterns in the AngularJS of old. People would just create these services which essentially were just global state, and inject them everywhere that needed access to something. Frankly, these are just a tiny bit better than putting lots of crap on your $rootScope and I don’t think it should be used in most codebases more than handful of times, and kept to a minimum.

Try to never use unless absolutely necessary

$watch

Well, $watch is still useful, of course, when you have to deeply watch some object, or when integrating with external libraries that don’t expose proper events or promises. And yet, these are rare scenarios. If all you need to do is know when a binding you got is changed, push that code to $onChanges and be done with it.

Never use

(Well, 99.9999% of the cases)

Events

AngularJS’s scopes have broadcasting capabilities, e.g. $broadcast and $emit. These allow passing messages between parent and child components across multiple layers. Having worked on dozens of AngularJS projects, I frankly don’t believe I cam across a codebase that incorporated these as a standard pattern and didn’t come to regret it later. Events, when used freely, usually end up causing code to be come a big spaghetti mess.

Do note though, that there are cases these events are useful, e.g. for implementing some sort of subscription mechanism for listening to changes in external data, like in your Store services. You can see an example of such a service here.

Did I miss any important patterns? Let me know!

But, a very common error that starts appearing in people’s consoles after this upgrade is the dreaded ”Possibly unhandled rejection” error.

Did you see this and wonder what does this mean? And more importantly, how the hell do you get rid of it? Worse, if you just follow the highest voted answer on StackOverflow you probably hide bugs and won’t be aware of it. Read on for the full gist.

What does this error mean?

Essentially, this error is printed to the console whenever a promise in your app is rejected (resolved with a failure), and there’s no .catch() block to handle that failure.

AngularJS added this to nudge developers to always handle possible errors. This is much like always adding an else to every if to make sure you handle error cases, etc. After all, every unhandled rejection might be an error that you forgot to account for, a bug waiting to happen.

A very common reason for it to come up in apps is things like modals being dismissed or “canceled”, and since the app has nothing to do in those scenarios the rejected promise goes unhandled.

Getting rid of it – the icky way

The Stack Overflow answer I linked to above basically shows you how to disable this new behavior introduced in 1.6:

1
2
3

app.config(function ($qProvider) {
    $qProvider.errorOnUnhandledRejections(false);
});

You might be tempted to just reach for this quick fix, but be aware that it doesn’t 100% resemble that behavior in 1.5.

The catch

Say that you make a simple typo, like we all do like 20 times a day. For example, you’re handling a response from $http that looks like this: {value: "stuff"}.

Now, spot the typo:

1
2
3

$http.get('/stuff').then(function(result) {
  handleResult(result.valye)
});

Of course, I mistyped value as valye. This code in version 1.5.x would result in an error in your console. So would it in 1.6, unless you turn off unhandled rejection errors. If you do it, this error would be swallowed, and you’ll be spending lots and lots of time debugging stuff.

That’s why I recommend solving this the right way, even though it might take more typing, unless you really really have no other choice.

Getting rid of it – the right way

Well, the trick to not having unhandled rejection errors is… well… handling them.

You should, after every every promise with a .then() block have a .catch() block (and no, .finally() blocks don’t help here):

1
2
3
4
5

$http.get('/stuff').then(function(result) {
  // ... stuff here
}).catch(function() {
  // handle errors
});

And what about cases where you absolutely don’t care about errors? The convention I’d have to recommend is explicitly handling errors in a way that says you’re aware of possible errors and don’t care:

1
2
3

$http.get('/stuff').then(function(result) {
  // ... stuff here
}).catch(angular.noop); // <-- look here!

We’re passing as a handler the angular.noop function, which a function that does… nothing. It’s the equivalent of function() {}. This saves you some typing, and whenever I see noop as opposed to an empty function, I know it was left there by intention, and not that someone forgot what they were doing half way through a commit.

Yeah, this is some more typing, but it’s all in favor of making more robust and bug-free apps. And I recommend setting up a shortcut in your favorite editor to add this (e.g. my TextExpander is set up to write .catch(angular.noop) whenever I type ;noop).

Happy erring!

But that’s just the tip of the iceberg, and ng-model allows for quite a bit more customization and integration in order to allow writing controls that work as smoothly as builtin ones.

In this post I’ll how to start integrating your control with the NgModelController and make your controls more capable and robust.

Our Starting Position

Let’s keep going with the example from the previous post, which was this very simple component:

1
2
3
4
5
6

angular.module('app').component('myCustomControl', {
  template: '...',
  bindings: {
    value: '=ngModel'
  }
});

A good first step would be to note that we can use this control with the name attribute, since ngModel looks for it:

1
2
3
4

<form name="$ctrl.form">
  <my-custom-control ng-model="someValue" name="foo">
  </my-custom-control>
</form>

By supplying name="foo" we can now access it from the form to make sure it’s valid, e.g. $ctrl.form.foo.$valid.

Changing Values Properly

In order to make our component work seamlessly with ng-change we will need to make sure that whenever the control’s value is changed as a result of a user interaction (not programmatically), we let NgModelController know.

First, we will need to make sure to require the NgModelController, and then, when the user clicks a button, invoke $setViewValue:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

angular.module('app').component('myCustomControl', {
  template: '...',
  require: {
    ngModelCtrl: 'ngModel'
  }
  bindings: {
    value: '=ngModel'
  },
  controller: function() {
    var self = this;
    self.userToggledOn = function() {
      self.ngModelCtrl.$setViewValue(true, 'click');
    }
  }
});

The important bits here are the require definition and the handling of the user’s click in userToggledOn, which calls NgModelController’s $setViewValue. Note that second parameter which lets it know what kind of DOM event triggered the change.

Defining emptiness

In my previous post I showed how required can simply be dropped in and used once ng-model is in place. That’s only the case, though, if your definition of “emptiness” matches the default logic as described in the documentation. But in case your control’s logic doesn’t match this, e.g. your model is an array and emptiness means the array is empty, you should override this behavior to let NgModelController know what you expect.

Inside your controller, after requiring ngModel as shown above, do this:

1
2
3
4
5
6
7
8

function SomeCtrl() {
  var self = this;
  self.$onInit = function() {
    self.ngModelCtrl.$isEmpty = function(value) {
      return !value || value.length === 0;
    };
  };
}

As you can see, we’re overriding the $isEmpty method, which is intended exactly for this purpose.

Also, note I’m making sure to access ngModelCtrl on $onInit, since it will not be defined earlier.

Handling Programatic Changes

An important part of the integration is to make sure the view is changed whenever the model value gets changed programmatically. For example, if the control’s ng-model attribute is a binding from its parent, and the parent changes that value, it usually means that the control should update the UI in order to show this state (e.g. because an update was received from the server).

In those scenarios, NgModelController expects us to override the $render method. NgModelController places a $watch on its value, and calls $render when it needs to change (though, note this watch is a shallow watch. If you’re mutating an object as your model, you will need to trigger it manually).

This would look roughly like so:

1
2
3
4
5
6
7
8
9

function SomeCtrl() {
  var self = this;
  self.$onInit = function() {
    // ... previous stuff
    self.ngModelCtrl.$render = function() {
      // Update the UI according to the self.ngModelCtrl.$viewValue
    }
  };
}

That’s it for now. There’s much more to ng-model, e.g. parsers and formatters that are handy when you want specific validations on inputs, etc. To be updated when I write about it, subscribe in the form below!

Handling inputs and forms with AngularJS can be a breeze, especially since AngularJS provides a lot of tools for efficiently doing just that. You need to add validations, like making sure the user filled all the fields, and it’s just a matter of adding a required attribute to all controls and checking the form’s $valid property.

I love it when instead of writing lots of code I simply do something along the lines of:

1

<button ng-disabled="!$ctrl.form.$valid" type="submit">Save</button>

(I’m not missing an ng-click there BTW, for submitting a form you should usually have ng-submit on the <form> element.)

But, what happens when you have use some custom control, instead of the browser’s builtins (e.g. inputs, textareas, selects)?

It usually looks ends up looking like this:

1

<my-custom-control value="$ctrl.someValue"></my-custom-control>

And suddenly, you can’t just use required, and the form’s $valid doesn’t work, and instead of using $ctrl.form.$valid to check everything is filled you have to write code along the lines of:

1
2
3

function isValid() {
  return self.form.$valid && self.someValue !== '';
}

Custom Controls Don’t Have to Suck

You don’t have to leave the comforts of Angular’s forms just because you have a custom control. You just need to make sure to wire things up properly.

It’s as easy as using ng-model to pass the value to the control, instead of some binding of yours. Here’s an example of refactoring a component to use ngModel:

1
2
3
4
5
6

angular.module('app').component('myCustomControl', {
  template: '...',
  bindings: {
    value: '=ngModel'
  }
});

You can still use the same name the component used before, such as value above, but make sure that the external name is ngModel. Using that component looks like so:

1

<my-custom-control ng-model="$ctrl.someValue" required>

Just by using the ng-model attribute, Angular’s ngModel directive will be used, and sprinkle its own magic. That means that it’ll register with the parent form, and add the needed validations.

For example, the required above will simply work now, and so will our original button, no need for custom code.

So please don’t write custom controls like an animal. Use Angular properly.

When working on web apps you’re going to be handling inputs quite a bit, and if so, you should be well equipped to use the right tools for the job. With AngularJS, those tools should include the extensive support for forms, inputs and validations.

I’ve covered the basics of writing forms before, but in this article I’d like to point out how Angular’s forms have a few magic properties that are worth knowing, since they can spare you some bugs and code!

First Things First: Getting Access to the Form

Forms in AngularJS have special properties, but how exactly are you meant to get access to these forms? The trick is to name the form. Once provide a name for your forms, AngularJS will automatically expose it under that name in your scope.

For example, say that we have this as part of the template of a component with $ctrl as its controller-as name:

1
2
3

<form name="$ctrl.exampleForm">
  <!-- inputs etc. go here.. -->
</form>

Setting the name to $ctrl.exampleForm means that in the template we can get access to the form, simply by using $ctrl.exampleForm. It can also be accessed from the controller’s code, using this.exampleForm.

Now that we know how to get access to the form, let’s start making use of it!

Testing Whether the User Has Interacted With the Form

A very common use case is the need to display certain error messages or help tips only after the user has started changing values in the form (or hasn’t started yet).

To do just that, forms in AngularJS come supplied with two handy boolean properties, $pristine and $dirty. These two booleans are always the negative of the other (i.e. $pristine === !$dirty).

When the form is in its virgin state and the user hasn’t changed anything yet, $pristine is set to true. Once the user has interacted with the form’s inputs, $pristine is set to false and $dirty is true.

In case you need to programmatically force the form back to its pristine state (e.g. the user clicked on reset, or after a successful save), you can call $ctrl.exampleForm.$setPristine().

Display Things After Form Submission

Sometimes, we want form validations to only be displayed after the user has clicked the save button, instead of changing as the user types or moves between fields.

In those cases, simply hiding validations until the form becomes $dirty won’t do, which is exactly why forms also have the handy $submitted property. This property gets set to true once the user has submitted the form, even if the form is invalid.

Submitting a form means clicking a button that has the attribute type="submit", or pressing Enter/Return inside an input.

AngularJS won’t prevent the form from being submitted if it’s invalid, meaning your ng-submit callback is called. You need to make sure not to act in case the form isn’t in a valid state.

Checking if the Form Is Valid

And just in order to check whether the form is valid or not, forms come equipped with a few more swanky properties.

First of all are the $valid and $invalid couple. If $valid is true – go right ahead. If $invalid is true – something is amiss.

In case the form is invalid, the form’s $error hash will contain all the necessary information about which fields are invalid and for what validations.

But, there’s another state here, which is when both are undefined. This is possible when the form has asynchronous validators. This means that it’s important to test these are true or false and not just “falsy” (e.g. undefined or null).

You can also check whether the form is currently pending, and see which of the validators are being processed, by accessing the $pending hash (which is structured similarly to $error).

There’s lots more that can be written about forms and their inputs in AngularJS, so if you’d like to hear more please subscribe below!

These errors almost never show up during development, but only after building the app for release. That’s because these problems are the result of minification, which usually isn’t setup to run during development (for easier debugging and faster build times).

In most online examples we’d simply write an injectable like so:

1
2
3

app.factory('Foo', function($http) {
  // Angular will inject $http
});

But, after minification Angular won’t be able to tell what to inject because argument names get mangled. That’s why Angular has its special injection annotations, e.g.:

1

app.factory('Foo', ['$http', function($http) { ... }]);

Or:

1
2

function Foo($http) {}
Foo.$inject = ['$http'];

These are of course a PITA to maintain, which is why I strongly recommend using an automatic took like babel-plugin-angularjs-annotate. But even when using it, one can forgot to write the 'ngInject'; directive somewhere.

In those scenarios, you’d normally only understand that there’s a problem in production, which is too late (and if you’re testing properly, it just means you’re pushing bugs too late into your development process anyway).

The Solution: Strict Mode

Strict mode is a configuration of Angular’s $injector, telling it not to accept injectables that aren’t annotated, even when running in development. (Note, this should not be confused with ES5’s strict mode.)

You set it by adding the ng-strict-di attribute to your ng-app element:

1

<body ng-app="app" ng-strict-di>

When you turn this switch on, AngularJS will throw an error whenever it encounters an injectable that’s missing proper annotations, even in development. This means you’ll get a clearer error that’s a lot easier to track down and at the right time. It does mean, though, that you should make sure to run your automatic annotator in development as well (which should be easy with babel-plugin-angularjs-annotate).

Switch strict mode on and save yourself some nasty debugging!

But, alas, it has been deprecated. Read on to understand what that means for your projects currently using it.

You Don’t Need to Type Annotations by Hand

Just because ng-annotate is deprecated it doesn’t mean it’s going to stop working. If it’s working for you right now, you can keep using that version and things should work as they have.

But, the “official” successor of ng-annotate is babel-plugin-angularjs-annotate (BPAA).

BPAA is actually a fork of ng-annotate that has been around for a while. While ng-annotate operated on JS source files, and had to be passed ES6 code after transpilation, BPAA is a Babel plugin and so operates as part of the transpilation process, and in a relatively transparent manner.

Given a build process/toolchain that’s already set up to use Babel, adding BPAA is often easier than adding ng-annotate. How much easier? You can follow the README I linked to above, but it generally boils down to a single NPM dependency and modifying a single line in your Babel configuration.

Since ng-annotate will no longer be maintained, I recommend switching to BPAA once you get the chance (nothing urgent though). I went through this process at a recent client and it was fairly simple and took less than an hour.

It also seems that BPAA is faster than ng-annotate, which makes for faster build times, that’s a small win.

Implicit Detection Considered Harmful

As part of the deprecation, the maintainers of both ng-annotate and BPAA agreed that implicit annotation detection is a bad practice and should be avoided.

What’s does that mean? Implicit detection means that the tools try and understand from the code whenever an Angular injectable is being declared and automatically insert annotations for it as needed, without any manual steps necessary by developers.

The maintainers talk about implicit detection causing a lot of problems, and recommend running BPAA with the explicitOnly setting. That setting means that you will need to markup class constructors like so:

1
2
3
4
5
6

class SomeCtrl {
  constructor($http) {
     'ngInject'; // <-- BPAA looks for this
    // ...
  }
}

And same goes for injectable functions:

1
2
3
4
5

angular.module('app').config(function($httpProvider) {
  'ngInject';

  // ...
});

This might seem weird if this is the first time you come across explicit mark up, but it’s easy enough and, along with strict-di, makes it impossible to come across injection bugs in runtime. While it would’ve been great if these explicit markers weren’t necessary, but since in most projects there’s at least one use case where they’re required I can see the logic of choosing the explicit route for safety.

“But I’m Not Using ES6!”

Well, surprisingly enough, you can incorporate Babel into your build process with BPAA as described above, to replace your existing ng-annotate step.

Babel doesn’t have to transpile ES6. If you don’t provide it with an ES6 (or ES2015, or whatever) preset, and just configure the BPAA plugin, Babel can be used instead of ng-annotate.

Open source sometimes moves fast, but the important point is that there’s a clear and relatively easy way to start using the supported tool (BPAA), and keep saving countless bugs and keystrokes!

One of those rules of thumb is: Don’t do in the template what can be done elsewhere.

In this post, I will go over the different symptoms of template overuse and why it can be problematic.

Template Overuse Symptoms

Template Overuse (noun): Performing work in the template that will be better placed somewhere else.

ng-click

A popular example is ng-click abuse:

1
2
3

<button ng-click="$ctrl.validate() && $ctrl.submit()">
  Submit
<button>

As you can see, the ng-click handler is first making sure that the form is valid before actually calling the submit operation.

This extra logic is misplaced.

A similar, yet different, example is:

1

<button ng-click="$ctrl.counter = 0">Reset</button>

As a guideline, template event handlers should trigger functions on the controller, and not any other expression/statement (e.g. the above would be ng-click="$ctrl.reset()").

This goes the same for similar directives, such as ng-submit, etc.

ng-init

This, for some reason beyond me, is not an uncommon sight:

1

<div ng-init="$ctrl.setup()">

In case you’re not aware of it, ng-init simply runs the code given to it when the template initializes. Its valid use cases are so rare, even the documentation warns against using it.

And yet, a GitHub search comes up with 785K+ hits at the time of this writing.

There’s a good place to initialize stuff: the controller’s $onInit hook!

Underusing CSS

All the power we get from templates might make it easy to forget that not all visual logic has to be done inside them. A good example is using ng-if or ng-class for targeting special cases that can be handled in CSS, like special casing the first element in a list, or coloring every other row, like I’ve shown here.

Forgetting the Basics

I see too many developers reinventing the wheel instead of making use of the power of the web.

Consider the first example here, which showed ng-click="$ctrl.validate() && $ctrl.submit()". There’s a known mechanism for preventing actions on buttons in case the form state is invalid, which is setting those buttons to be disabled. This can be done by using Angular’s validators, or even simply by using ng-disabled:

1
2
3

<button ng-disabled="!$ctrl.validate()" ng-click="$ctrl.submit()">
  Submit
</button>

Why is Overuse Bad?

First, having extra logic in the template makes it harder to refactor code at a later point. I’ve yet to come across the perfect IDE that makes refactoring templates as smooth as refactoring JavaScript code. If that’s the case, I opt for the style that makes refactoring easier.

Further, it’s very easy for templates to contain a bunch of dense expressions and overly long ng-if conditions. These in turn make code maintenance a PITA. Templates should be easy to change when view requirements change, and are best when they make it easy to understand and visualize what is happening on screen. The more code in your templates, the harder they become to follow.

Also, logic in template also makes it harder to properly unit test controllers. For example, if the template contains an ng-init hook, then usually the test would also have to invoke whatever expression the ng-init is calling.

Essentially, all these reasons boil down to complicated templates making code maintenance harder in the long term. Making a point of keeping templates succinct will make for a codebase that everyone will be happier working on.

Fixing Overuse

To repeat, the basic guidelines you should strive to follow are:

1. Don’t do in the template what can be done elsewere.
2. Template event handlers should trigger functions.
3. Remember the basics, like CSS and HTML form validation.
4. Don’t use ng-init. Just don’t.

In this post you will learn what automatic properties ng-repeat creates on the scope object, to make common tasks easier.

$index

The scope property is most probably the most popular one. When using ng-repeat, every block of repeated content has access to a property called $index. This property is a number, and contains the current index of the “loop” ng-repeat is doing:

1
2
3

<div class="task" ng-repeat="task in $ctrl.tasks">
  <span ng-bind="$index"></span>: <span ng-bind="task.name"></span>
</div>

As you can probably guess, this will display next to each task’s name its index in the $ctrl.tasks array.

Yet while it is most known, it is probably the one that should be used the least.

$first and $last

It’s common when using ng-repeat to add specific behavior to the first or last element of the loop, e.g. special styling around the edges.

I’ve seen too many programmers do it awkwardly using $index:

1

<div ng-if="$index == $ctrl.tasks.length - 1">Last</div>

Instead, ng-repeat already supplies you with two ready boolean properties. $first is true for the first element, and $last is true for the last element.

While we’re at it, I’ll mention that if all you’re doing here is styling, e.g. ng-class according to the first/last index, you might be better off doing this purely in CSS using the :first-child and :last-child pseudo-classes.

$middle

This simple property is simply used to tell whether the current element is neither the first element in the loop, nor the first.

It’s equivalent to !$first && !$last (to please the logic nerds, this is also !($first || $last), according to De Morgan’s Laws).

$odd and $even

These properties simply state whether the current $index is odd or even. It’s very common to style grid with alternating colors between rows for easier readability, and if you’re using ng-class to add an .even class, you’d better use $even instead of $index % 2 == 0.

Yet, again, I’ll say that in case you’re using this solely for styling, doing this in CSS would probably be the better choice, e.g. :nth-child(odd) and :nth-child(even).

You can read more about these properties and ng-repeat’s other features in the documentation.

In this post we’ll go over the different binding types and understand what, exactly, setting them as optional means, so you’ll know when to use it and what might happen if you don’t.

Two-way = bindings

Two-way bindings, when not specified as being optional, would only complain when the component tries to assign to them. That is because, by definition, Angular would attempt to update the parent component as well. If the parent never gave a value, Angular will not be able to update it, and so would throw a runtime exception.

For example, consider a component called userEditor that defines its bindings like this:

1
2
3

bindings: {
  user: '='
}

If you were to instantiate the component without the user bindings, e.g. <user-editor></user-editor>, at first nothing bad would happen. The component’s controller, when accessing the this.user property, will see that its value is undefined.

But, if the component would ever attempt a reassignment, such as this.user = {}, it would result in an error.

In those situations, in case the binding is not mandatory, you should specify it as being optional:

1
2
3

bindings: {
  user: '=?'
}

Then, reassigning would just silently work, without actually updating anything in the parent.

Though, I will stress that reassignments should be rare and you should probably be using one-way bindings, described below.

One-way < bindings

Since one-way bindings are, hmm, one-way, they don’t have the same problem as described above on reassignments. Angular just doesn’t care that the component is reassigning, and so, for these bindings, the behavior would be the same with or without the optional setting. If the user of the component does not pass a value for the binding, it would be undefined in the component’s controller and that’s it.

Yet it can be specified as being optional, by providing the value <? in the bindings definition (or scope if you’re using a directive).

Expression (function) & bindings

The & binding is mostly used in order to pass a callback to a component–a simple function that can be invoked by the component’s controller.

By default, when these bindings aren’t set up with an initial value by the parent component, they simply translate to a function that does nothing and returns undefined (also known as angular.noop). This makes it completely safe for the child component to call that binding without risking a crash, as a nice example of the Null Object pattern.

And yet, sometimes the component would need to know whether the callback was passed at all or not, e.g. to decide whether certain work needs to be done.

In those scenarios it is possible to specify the binding as being optional, with &?, and then it is passed to the controller as undefined, instead of angular.noop. Then the controller can check for it, e.g. if (this.callback), and take action according to the value.

This does mean, though, that the controller can no longer blindly invoke the binding; it has to check first that it is defined.

Bottom Line: Use Optional If You Mean It

As you might understand, one can do Angular for quite a while without ever having to use optional bindings. And yet, I would argue that they should always be used if, indeed, the bindings are optional.

Also since in two-way bindings it would be a bug waiting to happen to do otherwise. Yet mainly because I believe that doing so helps to write better, more maintainable code, that is later easier for future users of the component to reason about and understand (be those users other developers or future-you).

By adopting a convention across your codebase to always specify optional bindings when necessary, your team will have another aid for explicitly documenting your code.

Just remember to add that ? to the binding definition!

Controllers, being the basic building block in Angular, is also where you’ll get your biggest bang-for-the-buck for making the ES6 transition, in my opinion. That is, assuming your project is already making use of controller-as syntax, as opposed to exposing all of your controllers’ logic directly on the $scope object.

Let us look at an example controller:

1
2
3
4
5
6
7
8
9
10
11
12

function UsersCtrl(UsersStore) {
  var self = this;
  self.$onInit = function() {
    UsersStore.get().then(function(users) {
      self.users = users;
    }):
  };

  self.updateUser = function(user) {
    UsersStore.updateUser(user);
  };
}

(Note how all initialization is taking place inside the $onInit hook, which is a must starting from 1.6+)

Here is how the above controller would be written as a class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class UsersCtrl {
  constructor(UsersStore) {
    this.UsersStore = UsersStore;
  }

  $onInit() {
    this.UsersStore.get().then(users => {
      this.users = users;
    });
  }

  updateUser(user) {
    this.UsersStore.updateUser(user);
  }
}

The conversion steps are:

1. Change the function to be a class definition
2. Create inside it a constructor and move all injections to be its parameters. Inside this constructor assign every injected service to be a member of the new class.
3. Change every method declared previously as this.function to be declared as a regular method in a class.
4. Update all references to injected services to use the local properties, e.g. this.UsersStore instead of UsersStore.

Keep in mind that while classes have a constructor, you should not be using them for any real logic. You want to keep them as stupid as possible, only making sure to save injections. All other logic should be kept inside the $onInit hook.

Also note that ES6 classes do not have a concept of private methods/members. In the function syntax you could have declared a var innerData inside the UsersCtrl function, and innerData would not have been accessible to the template. That’s not the case with classes, and so I usually opt for a naming convention where templates are not allowed to access any methods or members on the controller that start with a _, e.g. _innerData.

You might find it icky, but that’s just the way it is. TypeScript, which you might also be considering, supports private members and even saves you the constructor boilerplate.

To recap, dependency injection annotations are used so that Angular would know what it should be injecting even when code is obfuscated/minified. This is a regular service with injection in ES5:

1
2
3

angular.module('app').service('Service', function($http) {
  this.get = function() { ... };
});

And that example with explicit annotations would look like so:

1
2
3

angular.module('app').service('Service', ['$http', function($http) {
  this.get = function() { ... };
}]);

How does this play along with ES6 classes?

The above example as a class looks like this:

1
2
3
4
5
6
7
8

angular.module('app').service('Service', Service);

class Service {
  constructor($http) {
    this.$http = $http;
  }
  get() { ... }
}

And in order to add proper annotations to it, simply add this line at the bottom:

1

Service.$inject = ['$http'];

That’s all there’s to it, if you insist on adding these manually.

But please, stop doing it like an animal, and incorporate something like babel-plugin-angularjs-annotate. Given that you’re using ES6, you very likely already transpiling your code into ES5, and this plugin can simply go over your code at that point and add these as necessary, given little hints. I’ve written more about it here.

Keep it classy! </dadpun>

Back then I made the point that, personally, I find factories require less boilerplate code and so they are often my choice.

Since then, a use case for using services has become more common, and that’s when using ES6/ES2015 classes.

When making use of classes, services are the right choice.

That’s because classes map naturally to an Angular service, let’s see how.

Take a look at this non-ES6 UsersStore:

1
2
3
4
5
6

angular.module('app').factory('UsersStore', function($http) {
  return {
    getAll: function() { ... },
    get: function(id) { ... }
  };
});

Converting this to an ES6 class would look like this:

1
2
3
4
5
6
7
8

class UsersStore {
  constructor($http) {
    this.$http = $http;
  }

  getAll() { ... }
  get(id) { ... }
}

The registration line would then be changed to this:

1

angular.module(‘app’).service(‘UsersStore’, UsersStore)

The behavior for all existing code that injects UsersStore will remain the same, this is a seamless transition.

An important note, though, is the way injection is now performed. Note that $http is now provided to the class’s constructor. In order to be able to access the injected service later, for example in the getAll method, we have to save it as a member. Then, the code in the converted getAll function should make sure to reference it as this.$http.

The extra typing around a constructor might put off some people, but looking at the bright side I find it helps making it more painful to write uber controllers and services that take on too much responsibility :)

Subscribe below to learn more about modern Angular and using Angular with ES6.

But, you may have come across the ng-bind directive, seen it used and realized it’s pretty much the same as straightforward interpolation. The above example using ng-bind would look like this:

1

Hello, <span ng-bind="$ctrl.name"></span>

Why do we have both {{}} and ng-bind?
Is there any reason to use one over the other?
In this post we’ll see exactly what are the differences and why ng-bind is preferable.

The original reason: Flash Of Unstyled Content

FOUC is a term that’s been around for quite some time. In Angular, it mostly refers to when a user might see a flash of a “raw” template, before Angular actually got to compiling it and handling it correctly. This happens from time to time when using {{ }} interpolation, since Angular has to go over the DOM, find these and actually evaluate the proper value to put in them.

It looks unprofessional and also might make non-technical people think there’s something wrong with the page.

ng-bind, on the other hand, makes this a non-issue. Since the directive operates as an element attribute, and not as the element’s text value, there’s nothing visible to the user before Angular finishes compiling the DOM.

This can also be circumvented using plain {{ }} by using tricks like ng-cloak, but I always found those to be a hassle.

The real reason: Performance

While it might seem like there’s no real reason to have a different performance impact if you’re writing {{ $ctrl.hello }} or <span ng-bind="$ctrl.hello "></span>, there is.

If you’ve been following my posts for a while, this shouldn’t be the first time you hear of a case where 2 things that seem like they should be pretty identical are actually very different when it comes to their run-time performance.

The thing is that when it needs to keep track of interpolated values, Angular will continuously re-evaluate the expression on each and every turn of the digest cycle, and re-render the displayed string, even if it has not changed.

This is opposed to ng-bind, where Angular places a regular watcher, and will render only when a value change has happened. This can have a major impact on the performance of an app, since there is a significant difference in the time each way adds to the digest cycle.

In my benchmarks, I’ve seen it go as far as being twice as fast to use ng-bind. You can see for yourself in these samples: with interpolation vs using ng-bind (and since these are basic interpolations, I wouldn’t be surprised the problem is worse for complicated expressions).

I’m not big for premature optimizations, but I do prefer sticking to a single way of doing things across a project. That is why I usually opt for sticking with ng-bind from the start.

Happy hacking!

Note that before diving into any optimizations, I highly suggest measuring and tracking down the problematic parts of your app.

Refreshing the whole list

Scenario

The list you’re rendering with ng-repeat isn’t edited/changed on a per-line basis, but simply reloaded, e.g. with a “Refresh” button that fetches the model again from the server and replaces the currently displayed list.

The act of re-rendering the whole list feels laggy. Usually this means there’s some jank, or the browser seems to freeze for a bit before actually rendering.

Improvement: track by

Use track by as detailed here. In the above scenario, when the list is changed Angular will destroy all DOM elements in the ng-repeat and create new ones, even if most of the list elements remained identical to their previous versions. This, especially when the list is big, is an expensive operation, which causes the lag.

track by lets Angular know how it is allowed to reuse DOM elements in ng-repeat even if the actual object instances have been changed. Saving DOM operations can significantly reduce lag.

A completely static list

Scenario

Your component displays a list of items that’s never changed as long as the component is alive. It might get changed when the user goes back and forth between routes, but once the data has been rendered and until the user moves on to a different place in your app, the data remains the same.

This is common in analytics apps that display results of queries and don’t actually manipulate the data afterwards.

While the list is on the screen the app might feel sluggish when interacting with it, e.g. clicking on buttons, opening dropdown, etc. This is usually caused by the ng-repeat elements introducing a lot of watchers to the app, which Angular then has to keep track of in every digest cycle.

I’ve seen my fare share of apps with simple-looking tables that made an app grind to a halt because under the hood they had thousands of watchers, heavy use of filters, etc.

Improvement: one-time bindings

Just for the case where the data should be rendered for a single time we were given the one-time binding syntax.

See the full explanation here, but basically by sprinkling some :: inside the ng-repeat elements’ bindings, a static list can have the number of watchers reduces to even nothing.

This means that once the rendering has finished the table has no performance impact on the page itself.

Editable content

Scenario

Your app displays a list or a table that can be changed by the user. Maybe some fields can be edited. Or perhaps there’s a table cell with a dynamic widget.

The list is big enough to have the same performance problems discussed in the previous part, but, since it needs to pick up on changes in the data, simply using one-time bindings breaks its usability. The list stops displaying changes, since all our watches are gone.

Improvement: immutable objects and one-time bindings

When you mutate one of the objects inside a list, Angular doesn’t recreate the DOM element for it. And since the DOM doesn’t get recreated, any one-time bindings will never be updated.

This is a great opportunity to start moving into the more modern one-way data flow and use immutable objects.

Instead of mutating the objects, e.g.:

1
2
3

function markTodoAsDone(todo) {
  todo.done = true;
}

… treat your models as immutable. When a change is needed, create a clone of the data and replace the model object inside the list:

1
2
3
4
5

function markTodoAsDone(todo) {
  var newTodo = angular.copy(todo);
  newTodo.done = true;
  todosListModel.replace(todo, newTodo);
}

Why does this work? Consider this template:

1
2
3
4
5

<div ng-repeat="todo in $ctrl.todosListModel.get()">
  <div ng-bind="::todo.title"></div>
  <div ng-if="::todo.done">Done!</div>
  <button ng-click="$ctrl.markTodoAsDone(todo)">Done</button>
</div>

Since all the bindings inside the ng-repeat template are one-time bindings, the only watcher here is the $watchCollection used by ng-repeat to keep track of $ctrl.todosListModel.get().

Had we simply mutated the todo object, the $watchCollection would not get triggered and nothing would get rendered. But since we’re putting a new object inside the list, $watchCollection will trigger a removal of the old todo, and an addition for the new one. The addition will create a new DOM element for our todo, and so it will get rendered according to its latest state.

Summary

ng-repeat can be tamed, at least partially, if you take care to use it according to your specific use case.

I hope this helps you speed your app a bit!