ES6 is becoming more and more popular among the JS crowd. I’m guessing that the first feature anyone that moves to ES6 starts using is arrow functions. And the recently released Angular 1.5 introduced support for injecting dependencies into arrow functions. Unfortunately this support added a couple of nice pitfalls for newcomers that are important to understand and avoid.
Quick background on arrow functions
In case you’re not familiar with these, they basically look like this:
1 2 3
Which, unsurprisingly, maps to:
1 2 3
Note: There’s a lot more syntax sugar that makes these awesome, like
array.map(x => x.name).
They can really save up on some typing and make code cleraer.
Get the cheat sheet at the bottom of this post for the full list!
An important feature of arrow functions is that they bind the
Most JS developers are well versed in the practice of keeping a reference to your “real”
this value, e.g.
var self = this or
var vm = this.
This is because every function you then declare inside the object might have a different
this value assigned to it at runtime, which makes for very fun bugs.
Arrow functions do this for you behind the scenes, so that inside an arrow function you can freely use
this and it’ll be the same
this as in its parent scope.
I like arrow functions very much.
First, because they mean I need to type less, which is always a good thing.
But mainly because using arrow functions means I don’t need to declare a
self var anymore or think about what
this means as often.
The main problem is when people assume they can just start using arrow functions everywhere, and say goodbye to the regular syntax. But that’s not the case.
Arrow functions should never be used for constructor functions.
They are always anonymous and have no
prototype, which means they are not
And of course using them as constructors is wrong since a constructor should not be using its parent scope’s
The Angular-Arrow function rule of thumb
The most common constructor functions in Angular are controllers and services.
So, to be safe, never use arrow functions in
module.service('Service', ...) calls and not when passing a controller function as
controller: ... when defining components/directives/etc. (and also not in
module.controller() calls, but you should hopefully not have any more of these).
Personally, I don’t like it when all my files don’t look the same, and I prefer my style guide to reduce thinking.
Because of that I simply recommend to not use arrow functions as the function parameter to any
module.something() call (where
something can be
run, etc.) and never when passing a
“Maintaining AngularJS feels like Cobol 🤷…”
You want to do AngularJS the right way.
Yet every blog post you see makes it look like your codebase is obsolete. Components? Lifecycle hooks? Controllers are dead?
It would be great to work on a modern codebase again, but who has weeks for a rewrite?
Well, you can get your app back in shape, without pushing back all your deadlines! Imagine, upgrading smoothly along your regular tasks, no longer deep in legacy.
Subscribe and get my free email course with steps for upgrading your AngularJS app to the latest 1.6 safely and without a rewrite.