Become a ninja with Angular

ES6 has just reached its final state, so it’s not yet fully supported by every browser. And, of course, some browsers will always be late to this game (even if, for once, Microsoft is doing a good job with Edge). You might be thinking: what’s the use of all this, if I need to be careful on what I can use? And you’d be right, because there aren’t that many apps that can afford to ignore older browsers. But, since virtually every JS developer who has tried ES6 wants to write ES6 apps, the community has found a solution: a transpiler.

A transpiler takes ES6 source code and generates ES5 code that can run in every browser. It even generates the source map files, which allows to debug directly the ES6 source code from the browser. At the time of writing, there are two main alternatives to transpile ES6 code:

Each has its own pros and cons. For example, Babeljs produces a more readable source code than Traceur. But Traceur is a Google project, so, of course, Angular and Traceur play well together. The source code of Angular itself was at first transpiled with Traceur, before switching to TypeScript. TypeScript is an open source language developed by Microsoft. It’s a typed superset of JavaScript that compiles to plain JavaScript, but we’ll dive into it very soon.

Let’s be honest Babel has waaaay more steam than Traceur, so I would advice you to use it. It is quickly becoming the de-facto standard in this area.

So if you want to play with ES6, or set it up in one of your projects, take a look at these transpilers, and add a build step to your process. It will take your ES6 source files and generate the equivalent ES5 code. It works very well but, of course, some of the new features are quite hard or impossible to transform in ES5, as they just did not exist. However, the current state is largely good enough for us to use without worrying, so let’s have a look at all these shiny new things we can do in JavaScript!

If you have been writing JS for some time, you know that the var declaration is tricky. In pretty much any other languages, a variable is declared where the declaration is done. But in JS, there is a concept, called "hoisting", which actually declares a variable at the top of the function, even if you declared it later.

So declaring a variable like name in the if block:

is equivalent to declaring it at the top of the function:

ES6 introduces a new keyword for variable declaration, let, behaving much more like what you would expect:

The variable name is now restricted to its block. let has been introduced to replace var in the long run, so you can pretty much drop the good old var keyword and start using let instead. The cool thing is, it should be painless to use let, and if you can’t, you have probably spotted something wrong with your code!

Since we are on the topic of new keywords and variables, there is another one that can be of interest. ES6 introduces const to declare…​ constants! When you declare a variable with const, it has to be initialized and you can’t assign another value later.

As for variables declared with let, constants are not hoisted and are only declared at the block level.

One small thing might surprise you: you can initialize a constant with an object and later modify the object content.

But you can’t assign another object:

Same thing with arrays:

Not a new keyword, but it can also catch your attention when reading ES6 code. There is now a shortcut for creating objects, when the object property you want to create has the same name as the variable used as the value.

Example:

can be simplified to

This new feature can also catch your attention when reading ES6 code. There is now a shortcut for assigning variables from objects or arrays.

In ES5:

Now, in ES6, you can do:

And you will have the same result. It can be a little disturbing, as the key is the property to look for into the object and the value is the variable to assign. But it works great! Even better: if the variable you want to assign has the same name as the property, you can simply write:

The cool thing is that it also works with nested objects:

And the same is possible with arrays:

Of course it also works for arrays in arrays, or arrays in objects, etc.

One interesting use of this can be for multiple return values. Imagine a function randomPonyInRace that returns a pony and its position in a race.

The new destructuring feature is assigning the position returned by the method to the position variable, and the pony to the pony variable! And if you don’t care about the position, you can write:

And you will only have the pony!

One of the characteristics of JavaScript is that it allows developers to call a function with any number of arguments:

The last case is the one that is the most relevant to us. Usually, we pass fewer arguments when the parameters are optional, like in the following example:

The optional parameters usually have a default value. The OR operator will return the right operand if the left one is undefined, as will be the case if the parameter was not provided (to be completely accurate, if it is falsy, i.e 0, false, "", etc.). Using this trick, the function getPonies can then be called:

This worked alright, but it was not really obvious that the parameters were optional ones with default values, without reading the function body. ES6 introduces a more precise way to have default parameters, directly in the function definition:

Now it is perfectly clear that the size parameter will be 10 and the page parameter will be 1 if not provided.

The default value can also be a function call:

or even other variables, either global variables, or other parameters of the function:

Note that if you try to access parameters on the right, their value is always undefined:

This mechanism for parameters can also be applied to values, for example when using a destructuring assignment:

ES6 introduces a new syntax to define variable parameters in functions. As said in the previous part, you could always pass extra arguments to a function and get them with the special arguments variable. So you could have done something like that:

But I think we can agree that it’s neither pretty nor obvious: since the ponies parameter is never used, how do we know that we can pass several ponies?

ES6 gives us a way better syntax, using the rest operator …​:

ponies is now a true array on which we can iterate. The for …​ of loop used for iteration is also a new feature in ES6. It allows to be sure to iterate over the collection values, and not also on its properties as for …​ in would do. Don’t you think our code is prettier and more obvious now?

The rest operator can also work when destructuring data:

The rest operator is not to be confused with the spread operator which, I’ll give you that, looks awfully similar! But the spread operator is the opposite: it takes an array and spreads it in variable arguments. The only examples I have in mind are functions like min or max, that receive variable arguments, and that you might want to call on an array:

One of the most emblematic new features, and one that we will vastly use when writing an Angular app: ES6 introduces classes to JavaScript! You can now easily use classes and inheritance in JavaScript. You always could, using prototypal inheritance, but that it was not an easy task, especially for beginners.

Now it’s very easy, take a look:

Class declarations, unlike function declarations, are not hoisted, so you need to declare a class before using it. You may have noticed the special function constructor. It is the function being called when we create a new pony, with the new operator. Here it needs a color, and we create a new Pony instance with the color set to "blue". A class can also have methods, callable on an instance, as the method toString() here.

It can also have static attributes and methods:

Static methods can be called only on the class directly:

A class can have getters and setters, if you want to hook on these operations:

And, of course, if you have classes, you also have inheritance out of the box in ES6.

Animal is called the base class, and Pony the derived class. As you can see, the derived class has the methods of the base class. It can also override them:

As you can see, the keyword super allows calling the method of the base class, with super.speed() for example.

The super keyword can also be used in constructors, to call the base class constructor:

Promises are not so new, and you might know them or use them already, as they were a big part of AngularJS 1.x. But since you will use them a lot in Angular, and even if you’re just using JS, I think it’s important to make a stop.

Promises aim to simplify asynchronous programming. Our JS code is full of async stuff, like AJAX requests, and usually we use callbacks to handle the result and the error. But it can get messy, with callbacks inside callbacks, and it makes the code hard to read and to maintain. Promises are much nicer than callbacks, as they flatten the code, and thus make it easier to understand. Let’s consider a simple use case, where we need to fetch a user, then their rights, then update a menu when we have these.

With callbacks:

Now, let’s compare it with promises:

I like this version, because it executes as you read it: I want to fetch a user, then get their rights, then update the menu.

As you can see, a promise is a 'thenable' object, which simply means it has a then method. This method takes two arguments: one success callback and one reject callback. The promise has three states:

When the promise is fulfilled, then the success callback is called, with the result as an argument. If the promise is rejected, then the reject callback is called, with a rejected value or an error as the argument.

So, how do you create a promise? Pretty simple, there is a new class called Promise, whose constructor expects a function with two parameters, resolve and reject.

Once you have created the promise, you can register callbacks, using the then method. This method can receive two parameters, the two callbacks you want to call in case of success or in case of failure. Here we only pass a success callback, ignoring the potential error:

Once the promise is resolved, the success callback (here simply logging the user on the console) will be called.

The cool part is that it flattens the code. For example, if your resolve callback is also returning a promise, you can write:

but more beautifully:

Another interesting thing is the error handling, as you can use one handler per promise, or one for all the chain.

One per promise:

One for the chain:

You should seriously look into Promises, because they are going to be the new way to write APIs, and every library will use them. Even the standard ones: the new Fetch API does for example.

One thing I like a lot in ES6 is the new arrow function syntax, using the 'fat arrow' operator (⇒). It is SO useful for callbacks and anonymous functions!

Let’s take our previous example with promises:

can be written with arrow functions like this:

How cool is it? THAT cool!

Note that the return is also implicit if there is no block: no need to write user ⇒ return getRights(user). But if we did have a block, we would need the explicit return:

And it has a special trick, a great power over normal functions: the this stays lexically bounded, which means that these functions don’t have a new this as other functions do. Let’s take an example, where you are iterating over an array with the map function to find the max.

In ES5:

You would expect this to work, but it doesn’t. If you have a good eye, you may have noticed that the forEach in the find function uses this, but the this is not bound to an object. So this.max is not the max of the maxFinder object…​ Of course you can fix it easily, using an alias:

or binding the this:

or even passing it as a second parameter of the forEach function (as it was designed for):

But there is now an even more elegant solution with the arrow function syntax:

That makes the arrow functions the perfect candidates for anonymous functions in callbacks!

This is a short one: you now have proper collections in ES6. Yay \o/! We used to have dictionaries filling the role of a map, but we can now use the class Map:

We also have a class Set:

You can iterate over a collection, with the new syntax for …​ of:

You’ll see that the for …​ of syntax is the one the Angular team chose to iterate over a collection in a template.

Composing strings has always been painful in JavaScript, as we usually have to use concatenation:

Template literals are a new small feature, where you have to use backticks (`) instead of quotes or simple quotes, and you have a basic templating system, with multiline support:

The multiline support is especially great when your are writing HTML strings, as we will do for our Angular components:

A standard way to organize functions in namespaces and to dynamically load code in JS has always been lacking. NodeJS has been one of the leaders in this, with a thriving ecosystem of modules using the CommonJS convention. On the browser side, there is also the AMD (Asynchronous Module Definition) API, used by RequireJS. But none of these were a real standard, thus leading to endless discussions on what’s best.

ES6 aims to create a syntax using the best from both worlds, without caring about the actual implementation. The Ecma TC39 committee (which is responsible for evolving ES6 and authoring the specification of the language) wanted to have a nice and easy syntax (that’s arguably CommonJS’s strong suit), but to support asynchronous loading (like AMD), and a few goodies like the possibility to statically analyze the code by tools and support cyclic dependencies nicely. The new syntax handles how you export and import things to and from modules.

This module thing is really important in Angular, as pretty much everything is defined in modules, that you have to import when you want to use them. Let’s say I want to expose a function to bet on a specific pony in a race and a function to start the race.

In races_service.js:

As you can see, this is fairly easy: the new keyword export does a straightforward job and exports the two functions.

Now, let’s say one of our application components needs to call these functions.

In another file:

That’s what is called a named export. Here we are importing the two functions, and we have to specify the filename containing these functions - here 'races_service'. Of course, you can import only one method if you need, you can even give it an alias:

And if you need to import all the methods from the module, you can use a wildcard '*'.

As you would do with other languages, use the wildcard with care, only when you really want all the functions, or most of them. As this will be analyzed by our IDEs, we will see auto-import soon and that will free us from the bother to import the right things.

With a wildcard, you have to use an alias, and I kind of like it, because it makes the rest of the code clearer:

If your module exposes only one function or value or class, you don’t have to use named export, and you can leverage the default keyword. It works great for classes for example:

Notice the lack of curly braces to import a default. You can import it with the alias you want, but to be consistent, it’s better to call the import with the module name (except if you have multiple modules with the same name of course, then you can chose an alias that allows to distinguish them). And of course, you can mix default export with named ones, but obviously with only one default per module.

In Angular, you’re going to use a lot of these imports in your app. Each component and service will be a class, generally isolated in their own file and exported, and then imported when needed in other components.

That ends our gentle introduction to ES6. We skipped some other parts, but if you’re comfortable with this chapter, you will have no problem writing your apps in ES6. If you want to have a deeper understanding of this, I highly recommend Exploring JS by Axel Rauschmayer or Understanding ES6 from Nicholas C. Zakas …​ Both ebooks can be read online for free, but don’t forget to buy it to support their authors, they have done a great work! Actually I’ve re-read Speaking JS, Axel’s previous book, and I again learned a few things, so if you want to refresh your JS skills, I definitely recommend it!

You may have heard that Angular apps can be written in ES5, ES6 or TypeScript. And you may be wondering what TypeScript is, or what it brings to the table.

JavaScript is dynamically typed. That means you can do things like:

And it works. That’s great for all sort of things, as you can pass pretty much any object to a function and it works, as long as the object has the properties the function needs:

This dynamic nature allows wonderful things but it is also a pain for a few others compared to more statically-typed languages. The most obvious might be when you call an unknown function in JS from another API, you pretty much have to read the doc (or, worse, the function code) to know what the parameter should look like. Take a look at our previous example: the method printColor needs a parameter with a color property. That can be hard to guess, and of course it is much worse in day-to-day work, where we use various libraries and services developed by fellow developers. One of Ninja Squad’s co-founders is often complaining about the lack of types in JS, and finds it regrettable he can’t be as productive and write as good code as he would in a more statically-typed environment. And he is not entirely wrong, even if he is sometimes ranting for the sake of it too! Without type information, IDEs have no real clue if you’re doing something wrong, and tools can’t help you find bugs in your code. Of course, we have tests in our apps, and Angular has always been keen on making testing easy, but it’s nearly impossible to have a perfect test coverage.

That leads to the maintainability topic. JS code can become hard to maintain, despite tests and documentation. Refactoring a huge JS app is no easy task, compared to what could be done in other statically-typed languages. Maintainability is a very important topic, and types help humans and tools to avoid mistakes when writing and maintaining code. Google has always been keen to push new solutions in that direction: it’s easy to understand as they have some of the biggest web apps of the world, with GMail, Google apps, Maps…​ So they have tried several approaches to front-end maintainability: GWT, Google Closure, Dart…​ All trying to help writing big webapps.

For Angular, the Google team wanted to help us writing better JS, by adding some type information to our code. It’s not a very new concept in JS, it was even the subject of the ECMASCRIPT 4 specification, which was later abandoned. At first they announced AtScript, as a superset of ES6 with annotations (types annotations and another kind I’ll discuss later). They also announced the support of TypeScript, the Microsoft language, with additional type annotations. And then, a few months later, the TypeScript team announced that they had worked closely with the Google team, and the new version of the language (1.5) would have all the shiny new things AtScript had. And the Google team announced that AtScript was officially dropped, and that TypeScript was the new top-notch way to write Angular apps!

I think this was a smart move for several reasons. For one, no one really wants to learn another language extension. And TypeScript was already there, with an active community and ecosystem. I never really used it before Angular, but I heard good things on it, from various people. TypeScript is a Microsoft project. But it’s not the Microsoft you have in mind, from the Ballmer and Gates years. It’s the Microsoft of the Nadella era, the one opening to its community, and, well, open-source. Google knows this, and it’s far better for them to contribute to an existing project, rather than to have to bear the burden to maintain their own. And the TypeScript framework will gain a huge popularity boost: win-win, as your manager would say.

But the main reason to bet on TypeScript is the type system it offers. It’s an optional type system that helps without getting in the way. In fact, after coding some time with it, I forgot about it: you can do Angular apps using TypeScript just for the parts where it really helps (more on that in a second) and simply ignore it everywhere else and write plain JS (ES6 in my case). But I do like what they have done, and we will have a look at what TypeScript offers in the next section. At the end, you’ll have enough understanding to read any Angular code, and you’ll be able to choose whether you want to use it or not (or just a little), in your apps.

You may be wondering: why use typed code in Angular apps? Let’s take an example. Angular 1 and 2 have been built around a powerful concept named "dependency injection". You might already be familiar with it, as it is a common design pattern used in several frameworks for different languages and, as I said, already used in AngularJS 1.x.

To sum up what dependency injection is, think about a component of the app, let’s say RaceList, needing to access the races list that the service RaceService can give. You would write RaceList like this:

But it has several flaws. One of them is the testability: it is now very hard to replace the raceService by a fake (mock) one, to test our component.

If we use the Dependency Injection (DI) pattern, we delegate the creation of the RaceService to the framework, and we simply ask for an instance. The framework is now in charge of the creation of the dependency, and, well, injects it:

Now, when we test this class, we can easily pass a fake service to the constructor:

But how does the framework know what to inject in the constructor? Good question! AngularJS 1.x relied on the parameter’s names, but it had a severe limitation, because minification of your code would have changed the param name…​ You could use the array syntax to fix this, or add a metadata to the class:

We had to add some metadata for the framework to understand what classes needed to be injected with. And that’s exactly what type annotations give: a metadata giving the framework a hint it needs to do the right injection. In Angular, using TypeScript, we can write our RaceList component like:

Now the injection can be done! You don’t have to use TypeScript in Angular, but clearly part of your code will be more elegant if you do. You can always do the same thing in plain ES6 or ES5, but you will have to manually add the metadata in another way (we’ll come back on this in more details).

That’s why we’re going to spend some time learning TypeScript (TS). Angular is clearly built to leverage ES6 and TS 1.5+, so we will have the easiest time writing our apps using it. And the Angular team really hopes to submit the type system to the standard committee, so maybe one day we’ll have types in JS, and all this will be usual.

Let’s dive in!

The general syntax to add type info in TypeScript is rather straightforward:

The types are easy to remember:

In such cases, the types are optional because the TS compiler can guess them (it’s called "type inference") from the values.

The type can also be coming from your app, as with the following class Pony:

TypeScript also supports what some languages call "generics", for example for an array:

The array can only contain ponies, and the generic notation, using <>, indicates this. You may be wondering what the point of doing this is. Adding types information will help the compiler catch possible mistakes:

So, if you need a variable to have multiple types, does it mean you’re screwed? No, because TS has a special type, called any.

It’s really useful when you don’t know the type of a value, either because it’s from a dynamic content or from a library you’re using.

If your variable can only be of type number or boolean, you can use a union type:

TypeScript also offers enum. For example, a race in our app can be either ready, started or done.

The enum is in fact a numeric value, starting at 0. You can set the value you want, though:

You can also set the return type of a function:

If the function returns nothing, you can show it using void:

That’s a good first step. But as I said earlier, JavaScript is great for its dynamic nature. A function will work if it receives an object with the correct property:

This function can be applied to any object with a score property. How do you translate this in TypeScript? It’s easy: you define an interface, like the "shape" of the object.

It means that the parameter must have a property called score of the type number. You can name these interfaces, of course:

Another treat of JavaScript is that arguments are optional. You can omit them, and they will become undefined. But if you define a function with typed parameter in TypeScript, the compiler will shout at you if you forget them:

To show that a parameter is optional in a function (or a property in an interface), you can add ? after the parameter. Here, the points parameter could be optional:

You may also be interested in describing a parameter that must have a specific function instead of a property:

The interface definition will be:

A class can implement an interface. For us, the Pony class should be able to run, so we can write:

The compiler will force us to implement a run method in the class. If we implement it badly, by expecting a string instead of a number for example, the compiler will yell:

You can also implement several interfaces if you want:

And an interface can extend one or several others:

When you’re defining a class in TypeScript, you can have properties and methods in your class. You may realize that properties in classes are not a standard ES6 feature, it is only possible in TypeScript.

Everything is public by default, but you can use the private keyword to hide a property or a method. If you add private or public to a constructor parameter, it is a shortcut to create and initialize a private or public member:

Which is the same as the more verbose:

These shortcuts are really useful and we’ll rely on them a lot in Angular!

When working with external libraries written in JS, you may think we are doomed because we don’t know what types of parameter the function in that library will expect. That’s one of the cool things with the TypeScript community: its members have defined interfaces for the types and functions exposed by the popular JavaScript libraries!

The files containing these interfaces have a special .d.ts extension. They contain a list of the library’s public functions. A good place to look for these files is DefinitelyTyped. For example, if you want to use TS in your AngularJS 1.x apps, you can download the proper file from the repo directly with NPM:

or download it manually. Then include the file at the top of your code, and enjoy the compilation checks:

/// <reference path="angular.d.ts" /> is a special comment recognized by TS, telling the compiler to look for the interface angular.d.ts. Now, if you misuse an AngularJS method, the compiler will complain, and you can fix it on the spot, without having to manually run your app!

Even cooler, since TypeScript 1.6, the compiler will auto-discover the interfaces if they are packaged in your node_modules directory in the dependency. More and more projects are adopting this approach, and so is Angular. So you don’t even have to worry about including the interfaces in your Angular project: the TS compiler will figure it out by itself if you are using NPM to manage your dependencies!

This is a fairly new feature, added only in TypeScript 1.5, to help supporting Angular. Indeed, as we will shortly see, Angular components can be described using decorators. You may not have heard about decorators, as not every language has them. A decorator is a way to do some meta-programming. They are fairly similar to annotations which are mainly used in Java, C# and Python, and maybe other languages I don’t know. Depending on the language, you add an annotation to a method, an attribute, or a class. Generally, annotations are not really used by the language itself, but mainly by frameworks and libraries.

Decorators are really powerful: they can modify their target (method, classes, etc.), and for example alter the parameters of the call, tamper with the result, call other methods when the target is called or add metadata for a framework (which is what Angular decorators do). Until now, it was not something possible in JavaScript. But the language is evolving and there is now an official proposal for decorators, which may be standardized one day in the future (possibly in ES7/ES2016). Note that the TypeScript implementation goes slightly further than the proposed standard.

In Angular, we will use the decorators provided by the framework. Their role is fairly basic: they add some metadata to our classes, attributes or parameters to say things like "this class is a component", "this is an optional dependency", "this is a custom property", etc. It’s not required to use them, as you can add the metadata manually (if you want to stick to ES5 for example), but the code will definitely be more elegant using decorators, as provided by TypeScript.

In TypeScript, decorators start with an @, and can be applied to a class, a class property, a function or a function parameter. They can’t be applied to a constructor, but can be applied to its parameters.

To have a better grasp on this, let’s try to build a simple decorator, @Log(), that will log something every time a method is called.

It will be used like this:

To define it, we have to write a method returning a function like this:

Depending on what you want to apply your decorator to, the function will not have exactly the same arguments. Here we have a method decorator that takes 3 parameters:

Here we simply log the method name, but you could do pretty much whatever you want: interfere with the parameters, the result, calling another function, etc.

So, in our simple example, every time the getRace() or getRaces() methods are called, we’ll see a trace in the browser logs:

As a user, let’s look at what a decorator in Angular looks like:

The @Component decorator is added to the class Home. When Angular loads our app, it will find the class Home and will understand that it is a component, based on the metadata the decorator will add. Cool, huh? As you can see, a decorator can also receive parameters, here a configuration object.

I just wanted to introduce the raw concept of decorators; we’ll look into every decorator available in Angular all along the book.

I have to point out that you can use decorators with Babel as a transpiler instead of TypeScript. There is even a plugin to support all the Angular decorators: angular2-annotations. Babel also supports class properties, but not the type system offered by TypeScript. You can use Babel, and write "ES6+" code, but you will not be able to use the types, and they are very useful for the dependency injection for example. It’s completely possible, but you’ll have to add more decorators to replace the types.

So my advice would be to give TypeScript a try! All my examples from here will use it. It’s not very intrusive, as you can use it just where it’s useful and forget about it for the rest. If you really don’t like it, it will not be very difficult to switch to ES6 with Babel or Traceur, or even ES5, if you are slightly crazy (but honestly, an Angular app in ES5 has pretty ugly code).

Components are an old fantasy in development. Something you can grab off the shelves and drop into your app, something that would work right away and bring a needed functionality to your users.

My friends, this time has come.

Well, maybe. At least, there is the start of something.

That’s not completely new. We have had components in web development for quite some time, but they usually require some kind of dependency, like jQuery, Dojo, Prototype, AngularJS, etc. Not necessarily libraries you wanted to add to your app.

Web Components attempt to solve this problem: let’s have reusable and encapsulated components.

They rely on a set of emerging standards that browsers don’t perfectly support yet. But, still, it’s an interesting topic, even if there’s a chance that we’ll have to wait a few years to use them fully, or even that the concept never takes off.

This emerging standard is defined in 4 specifications:

Note that the samples are most likely to work in a recent Chrome or Firefox browser.

Custom elements are a new standard allowing developers to create their own DOM elements, making something like <ns-pony></ns-pony> a perfectly valid HTML element. The specification defines how to declare such elements, how to make them extend existing elements, how to define your API, etc.

Declaring a custom element is done with a simple document.registerElement('ns-pony'):

Note that the name must contain a dash, so that the browser knows it is a custom element. Of course, your custom element can have properties and methods, and it also has lifecycle callbacks, to be able to execute code when the component is inserted or removed, or when one of its attributes changes. It can also have a template of its own. Maybe the ns-pony displays an image of the pony or just its name:

If you try to look at the DOM, you’ll see <ns-pony><h1>General Soda</h1></ns-pony>. But that means the CSS and JavaScript logic of your app can have undesired effects on your component. So, usually, the template is hidden and encapsulated in something called Shadow DOM, and you’ll only see <ns-pony></ns-pony> if you inspect the DOM, despite the fact that the browser displays the pony’s name.

With a mysterious name like this, you expect something with great powers. And surely it is. The Shadow DOM is a way to encapsulate the DOM of our component. This encapsulation means that the stylesheet and JavaScript logic of your app will not apply on the component and ruin it inadvertently. It gives us the perfect tool to hide the internals of a component, and be sure that nothing leaks from the component to the app, or vice-versa.

Going back to our previous example:

If you try to inspect it now you should see:

Now, even if you try to add some style to the h1 elements, the visual aspect of the component won’t change at all: that’s because the Shadow DOM acts like a barrier.

Until now, we just used a string as a template of our web component. But that’s usually not the way you do that. Instead, the best practice is to use the <template> element.

A template specified in a <template> element is not displayed in your browser. Its main goal is to be cloned in an element at some point. What you declare inside will be inert: scripts don’t run, images don’t load, etc. Its content can’t be queried by the rest of the page using usual method like getElementById() and it can be safely placed anywhere in your page.

To use a template, it needs to be cloned:

Maybe we could declare this in a single file, and we would have a perfectly encapsulated component…​ Let’s do this with HTML imports!

This is the last specification. HTML imports allow to import HTML into HTML. Something like <link rel="import" href="ns-pony.html">. This file, ns-pony.html, would contain everything needed: the template, the scripts, the styles, etc.

If someone wants to use our wonderful component, they just have to use an HTML import and they are good to go!

All these things put together make the Web Components. I’m far from being an expert on this topic, and there are all sorts of twisted traps on this road.

As Web Components are not fully supported by every browser, there is a polyfill you can include in your app to make sure it will work. The polyfill is called web-component.js, and it’s worth noting that it is a joint effort from Google, Mozilla and Microsoft among others.

On top of this polyfill, a few libraries have seen the light. All aim to facilitate working with Web Components, and often come with some ready-to-use Web Components.

Among the most notable initiatives, you find:

I won’t go into the details, but you can easily use an already existing Polymer Component. Let’s say you want a Google Map in your app:

There are a LOT of components out there. You can have an overview on https://customelements.io/.

Polymer also helps you build your own components:

and use them:

You can do a lot of cool things with Polymer, like two-way data binding, default values for attributes, emit custom events, react on attribute changes, repeat elements if we give a collection to a component, etc.

That’s obviously far too short a chapter to tell you everything there is to say on Web Components, but you’ll see that some of the concepts are going to pop out along your read. And you’ll definitely see that the Google team designed Angular to make it easy to use Web Components along our Angular components.

Let’s start by creating our first Angular app and our first component, with a minimum of tooling. You’ll have to install Node.js and NPM on your system. The best way to do that depends on your operating system - you can find more information on the official website. Make sure you have a recent enough version of Node.js (by executing node --version), something like 4.4+. We’ll write our app in TypeScript, so you’ll have to install it via npm:

Then, create a new, empty folder for our experiment, and use tsc from that new empty folder to initialize a project. tsc stands for TypeScript Compiler. It’s provided by the typescript NPM module we just installed globally:

This will create a file, tsconfig.json, which stores the TypeScript compilation options. As we saw in the previous chapters, we are using TypeScript with decorators (hence the last two flags), and we want our code to transpile to ECMASCRIPT 5, allowing it to run in every browser. The sourceMap option allows generating source maps, i.e. files that contain a mapping between the generated ES5 code and the original TypeScript code. Those source maps are used by the browser to let you debug the ES5 code it executes by stepping through the original TypeScript code that you have written.

We now want to start using our preferred IDE. You can use pretty much anything you want, but you should activate the TypeScript support for maximum comfort (and make sure you are using TypeScript 1.5+). Pick your favorite IDE: Webstorm, Atom, VisualStudio Code…​ All of them have great support for TypeScript.

The TypeScript compiler (and usually the IDE) relies on the tsconfig.json file to know what options it should use. The file should look like the following:

You can see that a few options have been added by default. An interesting one is the module option, telling us that our code will be packaged in CommonJS modules. It will be important in a moment.

We now need to add the Angular library and our code. For the Angular library, we are going to download it using NPM, a great tool to manage dependencies.

To avoid a few problems, we’ll use NPM version 3. Check which version you have with:

If you don’t have NPM version 3, you can easily update NPM:

Now that’s done, let’s start by creating the package.json file, containing all the information that NPM needs. You can answer Enter to every question.

Then, let’s install Angular and its dependencies.

You can have a look at your package.json file, it should now contain the following dependencies:

Last thing to make the compiler happy, you have to install the typings for the things related to ES6. The easiest way is to install the typings for core-js:

The tooling is now in place, let’s create our first component!

Create a new file, called app.component.ts.

Now we are ready to launch the TypeScript compiler, using the watch mode to compile the files when we save. Sometimes your IDE will do that for you.

You should see something like:

You can let this run in the background and open a new terminal for what comes next.

When you save your file, you should see a new file app.component.js popping in the directory: it’s the TypeScript compiler doing its job. You should see the source map file as well. If not, you probably killed your TypeScript compiler watching for changes, so you might run it again with tsc --watch, and leave it running in the background.

As we saw in the previous section, a component is a combination of a view (the template) and some logic (our TS class). Let’s create a class:

Our application itself is a simple component. To tell Angular that it is a component, we use the @Component decorator. To be able to use it, we have to import it:

If your IDE supports it, code completion should work as the Angular dependency has its own d.ts files in the node_modules directory, and TypeScript is able to detect it. You can even navigate to the type definitions if you want to.

TypeScript will bring its type-checking to the table, so you’ll see what mistakes you make as you type. But the errors are not necessarily blocking: if you forget to add the type information to your variable, the code will still compile to JavaScript and run properly.

I try to keep the TypeScript errors count to 0, but you can do as you want. As we are using source maps, you can see the TS code directly from your browser, and even debug your app by setting breakpoints in the TypeScript code.

The @Component decorator is expecting a configuration object. We’ll see later in details what you can configure here, but for now only one property is expected: the selector one. It will tell Angular what to look for in our HTML pages. Every time the selector we have defined is found in our HTML, Angular is going to replace the element selected by our component:

So, here, every time our HTML will contain an element like <ponyracer-app></ponyracer-app>, Angular will instantiate a new instance of our PonyRacerAppComponent class.

A component must also have a template. We could externalize the template in another file, but for our first time, let’s keep it simple, and inline it:

Don’t forget to import the Component decorator. You may forget to do so at the beginning, but it won’t last, as the compiler will yell at you! ;)

You’ll see that most of the things we need are in the @angular/core module, but that’s not always the case. For example, when dealing with HTTP, we’ll use imports from @angular/http; or, if we use the router, we’ll import from @angular/router, etc.

Like we briefly said in the previous chapter, we are going to group our components and other pieces we’ll see later in coherent entities: Angular Modules.

An Angular Module is different from the ES6 Modules we crossed earlier: here we are talking about application modules.

Your application will always have at least one module, the root module. Maybe, later, when your application grows, you’ll add other modules, by feature. For example, you could add a module dedicated to the Admin part of your application, containing all the components and the logic for this part. But we’ll come back to this later. We’ll also see that third party libraries and Angular itself expose modules, that we can use in our app.

To define an Angular Module for our little app, we have to create a class. Usually, this is done in a separate file, called app.module.ts for the root module.

The class has to be decorated with @NgModule.

Like the @Component decorator, it takes a configuration object.

As we are building an app for the browser, the root module should import BrowserModule. This is not the only target possible for Angular, you could choose to render the app on the server for example, and therefore import another module. BrowserModule contains all kinds of useful stuff we will use later. A module can choose to export components, directives and pipes. When you import a module, you will make all the directives, components and pipes exported by the imported module usable in your module. Our root module won’t be imported in another module, so we don’t have exports, but we will have several imports in the end.

The terminology is not beginner friendly here. We were talking about ES6 and TS modules in the first chapters, which define imports and exports. And now we are talking about Angular modules, which also have imports and exports…​ I’m not a fan of having the same terms for different things, so let me explain a little bit more.

You can see an ES6 or TS import purely as a language feature, like an import statement in Java: it allows using the imported classes/functions in your source code. It also declares a dependency for the bundler or module loader (Webpack or SystemJS, for example), which knows that if a.ts is loaded, then b.ts must also be loaded since a imports b. You have to use imports and exports with ES6 and TypeScript, whether or not you’re using Angular or any other framework.

On the other hand, importing an Angular module (for example BrowserModule) in your own Angular module (AppModule), has a functional meaning. It tells Angular: all the components, directives and pipes that are exported by BrowserModule should be made available to my Angular components/templates. It has no special meaning for the TypeScript compiler.

Back to NgModule: in its configuration object, we must declare the components that belong to our root module, with the declarations field. Let’s add the component we have carefully crafted: PonyracerAppComponent.

Since this is the root module, we need to tell Angular which component is the root component, i.e. the component that will be started when we bootstrap the app. That’s what the bootstrap field of the configuration object is for:

Module ready, let’s bootstrap the app!

Finally, we need to start our app, using the bootstrapModule method. This method is exposed on an object returned by a method called platformBrowserDynamic. You have to import it too, from @angular/platform-browser-dynamic. Now, that’s a strange module! Why is it not @angular/core? Good question: it’s because you might want to run your app somewhere else than in a browser, as Angular supports server-side rendering or running in a Web Worker for example. And in these cases, the bootstrap logic would be a bit different. But we’ll see this later, as we are just focusing on the browser right now.

Let’s create another file, for example main.ts, to separate the bootstrap logic:

Yay! But wait a second. We don’t have any HTML file, do we? You’re right about that!

Create another file named index.html and add the following content:

We now need to add scripts to our HTML files. In AngularJS 1.x, it was simple: you just needed to add a script for angular.js, and a script for every JS file you wrote, and you were ready to go. There was a downside though: everything had to be loaded statically, at startup, which could lead to long startup times for big applications.

With Angular, things are more complicated, but complexity comes with additional power. Angular is now bundled in modules (ES6 modules), and these modules can be loaded dynamically. Our app is also bundled in modules, as we saw earlier.

There are a few problems though:

To load our modules, we will thus need to rely on a tool: SystemJS. SystemJS is a small module loader: you add it (statically) into your HTML page, you tell it where modules are located on your server, and you load one of them. It automatically figures out the dependencies between modules, and downloads the ones used by your application.

This will lead to a bazillion of JS file downloads. That is fine during development, but it is a problem for production. Fortunately, SystemJS also comes with a tool that can pack several small modules into bigger bundles. When a module is needed, the bundle containing that module (and several other ones) will then be downloaded.

Note that this is not the only tool that can do this job, you could use another one like Webpack if you wanted to.

Let’s install SystemJS:

We need to load SystemJS statically, and to tell it where our bootstrap module is (in main). We also need to tell it where to find the dependencies of our application, like @angular. But first, we need to include reflect-metadata and zone.js:

OK! Let’s start an HTTP server to serve this mini app. I’m going to use http-server, a node tool that does pretty much what its name says. But you may of course use whatever web server you prefer: Apache, Nginx, Tomcat, etc. To install it, use npm:

To start it, go to your directory, and enter:

Now it’s time for the show! Open your browser to http://localhost:8080.

You should now briefly see "You will see this while Angular start the app!", and then "PonyRacer" should appear! Your first component is a success!

It’s not really a dynamic app, and we could have done the same in one second in a static HTML page, I’ll give you that. So let’s jump to the next sections, and learn all about dependency injection and templating.

In a real project, you’ll probably have to set up several other things like:

And it’s a bit cumbersome to setup everything yourself, even if I think it’s necessary to do it once to understand what’s going on.

These past few years, a lot of small project generators have seen the light, pretty much all using the great Yeoman. It used to be the case for AngularJS 1.x, and there are already a few attempts for Angular.

But this time, the Google team has been working on this issue, and they have come up with something: Angular CLI.

Angular CLI is a command line utility to easily quick start a project, already configured with Webpack as a build tool, tests, packaging, etc.

The idea is not new, and is in fact borrowed from another popular framework: EmberJS and its popularly acclaimed ember-cli.

The tool is still under development, but I think it will be the de facto standard to create Angular apps in the future, so you can give it a try.

In fact I think you should give it a try: you will have the equivalent of what we just did manually, plus a ton of cool stuff.

This will create a project skeleton. You can start your app with:

This will start a small HTTP server locally, with a hot reload configuration. That means every time you are going to modify and save a file, the app will refresh in your browser.

A few other possibilities are available, like creating a component skeleton:

This will create a component file, with its associated template, stylesheet and test file.

The tool is not only here to help us develop the application, it also comes with a plugin system that will simplify a few tasks like deployment. For example, you can quickly deploy on Github Pages, using the github-pages plugin:

In the long term, this is going to be great! We’ll have the same code organization across projects, a common way to build and deploy apps, and probably a huge eco-system of plugins for simplifying some tasks.

So go have a look at Angular CLI!

Interpolation is a big word for a simple concept.

Quick example:

We have a PonyRacerAppComponent component that will be activated every time Angular finds a <ponyracer-app> tag. The PonyRacerAppComponent class has a property, numberOfUsers. And the template has been augmented with an <h2> tag, using the famous double curly braces (a.k.a. "mustaches") to indicate that an expression has to be evaluated. This kind of templating is called interpolation.

We should now see in the browser:

as {{ numberOfUsers }} will be replaced by its value. When Angular detects a <ponyracer-app> element in the page, it creates an instance of the PonyRacerAppComponent class, and this instance is the evaluation context of the template’s expressions. Here the PonyRacerAppComponent instance sets the numberOfUsers property to '146', so we have '146' displayed on screen.

The magic is that, whenever the value of numberOfUsers changes in our object, the template will be automatically updated! That’s called 'change detection', and it’s one of the great features of Angular.

One important fact to remember, though: if we try to display a variable that does not exist, then, instead of displaying undefined, Angular is going to display an empty string. The same will happen for a null variable.

Let’s say that, instead of a simple value, our first component has a more complex user object, reflecting the current user.

As you can see, we can interpolate more complex expressions, like accessing the property of an object.

What happens if we have a typo in our template, with a property that does not exist in the class?

When loading the app, you will have an error, telling you that this property does not exist:

That’s great, because now you are quite sure that your templates are correct. One of the most often encountered problem in AngularJS 1.x was that this type of error could not be detected, and you could lose quite some time trying to figure out what was going on (usually a typo, like {{ users.name }} instead of {{ user.name }}). We have given quite a few training sessions, and I can assure you that 30% of beginners were having this problem on the first day. I got a bit tired of it, and I even submitted a pull-request to display a warning when the parser would find an unknown variable, which was refused for valid reasons and with a comment from the core team saying they had an idea on how to solve this in Angular. And they did!

One last little but handy feature. What happens if my user object is in fact fetched from the server, and thus initialized to undefined before being valued with the result of the server call? Is there a way to avoid the errors when the template is compiled?

Yes, there is: instead of writing user.name, you write user?.name:

And you don’t have errors anymore! The ?. is sometimes called the "Safe Navigation Operator".

So we can write our templates more safely, and be assured that they will behave properly.

Let’s go back to our example. We are now displaying a greeting message. Maybe we can go a step further and display the upcoming pony races.

That should lead us to write our second component. For now, we’ll just make it simple:

Nothing fancy: a simple class, decorated with @Component to give it a selector to match and an inline template.

Now we want to include this component in our PonyRacerAppComponent template. What do we need to do?

We have our app component, PonyRacerAppComponent, where we want to display the pony races component, RacesComponent.

As you can see, we added the RacesComponent component in the template, by including a tag whose name matches the selector we defined for the component.

Buuuuuut, that will not work: your browser will not display the races component.

Why is that? The reason is simple: Angular doesn’t know about this RacesComponent yet.

But the fix is simple. Do you remember that we had to add PonyRacerAppComponent in the declarations of the @NgModule decorator? Now, since we have a second component, it must be declared, too.

RacesComponent is not the root component of our application, so it must be in the declarations, but not in the bootstrap.

Note that you will pass the class directly, so you’ll have to import it. And in order to be able import it, you need to export the class RacesComponent in its source file races.component.ts (read the section about ES6 modules again if that’s not clear for you). So RacesComponent will look like:

Now, our races component will proudly be displayed in our browser:

Interpolation is only one of the ways to have dynamic parts in your template.

In fact, the interpolation we just saw is just an easy way to use what is the core of Angular templating system: property binding.

In Angular, every DOM property can be written to via special attributes on HTML elements surrounded with square brackets []. It looks weird at first, but in fact it is valid HTML (it surprised me too). An HTML attribute can start with pretty much anything you want except a few characters like quotes, apostrophes, slashes, equals, spaces…​

I’m talking about DOM properties, but maybe this is not clear for you. We usually write to HTML attributes, right? Right, usually we do. Let’s take this simple HTML:

The input tag above has two attributes: a type attribute and a value attribute. When the browser parses this tag, it creates a corresponding DOM node (an HTMLInputElement if we want to be accurate), which has the matching properties type and value. Each standard HTML attribute has a corresponding property in the DOM node. But the DOM node also has additional properties, which don’t have a corresponding attribute. For example: childElementCount, innerHTML or textContent.

The interpolation we had above to display the user’s name:

is just sugar syntax for the following:

The square bracket syntax allows to modify the DOM property textContent, and we give it the value user.name which will be evaluated in the context of the current component instance, as it was for the interpolation.

Note that the parser is case-sensitive, so you have to write the property name with the correct case: textcontent or TEXTCONTENT will not work, it has to be textContent.

DOM properties have a great advantage over HTML attributes: they have up-to-date values. In my input example, the value attribute will always contain 'hello', whereas the value property of the DOM node is dynamically modified by the browser, and thus contains whatever the user has entered in the text field.

Finally, properties can have boolean values, whereas some attributes can only reflect it by being present or absent on the start tag. For example, you have the selected attribute on the <option> tag: no matter what value you give it, it will select the option, as long as it is present.

With properties access like Angular gives us, you can write:

And the pony will be selected if isPonySelected is true, and not be selected if it is false. And whenever the value of isPoneySelected changes, the selected property will be updated.

You can do a lot of cool things with this, things that were cumbersome in AngularJS 1.x. For example, having a dynamic source URL for an image.

This syntax has a major problem: the browser will try to fetch the image as soon as it reads the src attribute. You can see that it will fail: it will make an HTTP request to {{ pony.avatar.url }} which is not a valid URL…​

In AngularJS 1.x, there was a special directive to take care of that: ng-src.

Having ng-src instead of src did solve the problem, as it tricked the browser into ignoring it. Once AngularJS had compiled the app, it added the src attribute with a correct URL, hence triggering the image download. Cool! But it had two downsides:

If this a Web Component that you want to use, you have no easy way to pass a dynamic value with most JS frameworks, except if the developer of the Web Component had taken extra care to make it possible. Read the chapter on Web Components for more information.

A Web component should act like a browser element. They have a DOM API based on properties, events and methods. With Angular, you can do:

And it works!

Angular will maintain the properties and attributes in sync.

No more directives to learn! If you wish to hide an element, you can use the standard hidden property:

And the div will be hidden only when isHidden is true, as Angular will work directly with the hidden property. No more ng-hide, and this is just one of the dozens of directives that were used in Angular 1.

You can also access nested properties like the color attribute of the style property.

If the foreground attribute is changing to 'green', then the text will update its color to 'green' too!

So Angular is using properties. Which values can we pass? We already saw the interpolation property="{{ expression }}":

is the same as [property]="expression" (which you will usually prefer):

If you want to write 'Pony' followed by the pony’s name, you have two options:

If your value is not a dynamic one, you can simply write property="value":

All of these are equivalent, and the syntax doesn’t depend on how the developer chose to design their component, as it was the case in AngularJS 1.x where you had to know if the component was expecting a value or a reference for example.

Of course, the expression can also contain function calls:

If you’re developing a webapp, you know that displaying things is just one part of the job: you also have to deal with user interactions. To allow this, the browser fires events, which you can listen to: click, keyup, mousemove, etc. AngularJS 1.x had one directive per event: ng-click, ng-keyup, ng-mousemove, etc. In Angular, this is simpler, no more directives to remember.

Going back to our RacesComponent, we now want to have a button that will display the races when clicked.

Reacting on an event can be done as follow:

A click on the button of the example above will trigger a call to the component method onButtonClick().

Let’s add this to our component:

If you try this in your browser, you should initially see:

And after your click, '0 races' should become '2 races'. Yay \o/

The statement can be a function call, but it can be any executable statement, or even a sequence of executable statements, like:

However I would not advise you to do this. Using methods is a better way of encapsulating the behavior: it makes your code easier to maintain and test, and it makes the view simpler.

The cool thing is that it works with standard DOM events, but also with custom events that might fire from your Angular components or from web components. We’ll see later how to fire custom events.

For the moment, let’s say the RacesComponent component emits a custom event to notify the app that a new race is available.

Our template in the PonyRacerAppComponent component would then look like:

We can easily figure that the <ns-races> component has a custom event newRaceAvailable and that, when this event is fired, the method onNewRace() of our PonyRacerAppComponent is called.

Angular will listen for the event on the element and on its children, so it will react to events that bubble. Consider the template:

Even though the user clicks on the button embedded inside the div, the onButtonClick() method will be called, because the event bubbles up.

Oh, and you can access the event in the method called! You just have to pass $event to your method:

Then you can handle the event in your component class:

By default, the event will continue to bubble up, eventually triggering other event listeners up in the hierarchy.

You can use the event to prevent the default behavior and/or cancel propagation if you want:

One cool feature is that you can also easily handle keyboard events with:

Every time you will press the space key, the onSpacePress() method will be called. And you can do crazy combo, like (keydown.alt.space), etc.

To conclude this part, I want to point that there is a big difference between something like:

and

In the first case, with property binding, the doSomething() value is called an expression, and will be evaluated at each change detection cycle to see if the property needs to be updated.

In the second case, however, with event binding, the doSomething() value is called a statement, and will be evaluated only when the event is triggered.

By definition they have completely different goals and, as you can suspect, they have different restrictions.

Expressions and statements differ in several ways.

An expression will be executed many times, as part of the change detection. It should thus be as fast as possible. Basically, an Angular expression is a simplified version of an expression you could write in JavaScript.

If you are using user.name as an expression, user should be defined, otherwise Angular will throw an error.

An expression must be single: you can’t chain several ones separated with a semi-colon.

An expression should not have any side effect. That means it can’t be an assignment, for example.

It can not contains keywords, like if, var, etc.

A statement, on the other hand, is triggered on the matching event. If you try to use a statement like race.show() where race is undefined, you will have an error. You can chain several statements, separated with a semi-colon. A statement can, and generally should, have side effects. That’s the point of reacting to an event: to make something happen. A statement can be a variable assignment, and can contain keywords.

When I say that Angular will look in the component instance to find a variable, it is not technically correct. In fact, it will check the component instance and the local variables. Local variables are variables that you can dynamically declare in your template using the # syntax.

Let’s say you want to display the value of an input:

Using the # syntax, we are creating a local variable name referencing the DOM object HTMLInputElement. This local variable can be used anywhere in the template. As it has a value property, we can display this property in an interpolated expression. I’ll come back to this example later.

Another useful usage of local variables is when you want to execute some kind of action on another element.

For example, you may want to give the focus on an element when you click on a button. This was a bit cumbersome in AngularJS 1.x, as you had to create a custom directive and so on.

The focus() method is a standard part of the DOM API, and we can leverage this. Using a local variable, it’s a no-brainer in Angular:

It can also be used with a custom component - one we created in our app, imported from another project, or even with a real Web Component:

Here, the button can start playing the video of the <google-youtube> component. This is actually a real Web Component written with Polymer! This component has a play() method that Angular will call when you click on the button, which is pretty cool!

Local variables have a few use cases, and we will gradually see them. One of them is described in the very next section.

Now, our RacesComponent is still not displaying the races :) The "proper way" in Angular would imply to create another component RaceComponent to display each race. We are going to do something slightly simpler, and just write a simple <ul><li> list.

Property and event binding is great, but it does not let us change the DOM structure, like iterating over a collection and adding an element per item. To do so, we need to use structural directives. A directive in Angular is really close to a component, but does not have a template. It is used to add behavior to an element.

The structural directives provided by Angular rely on using a ng-template element, inspired from the template standard tag of the HTML specification. It even used to called template before version 4.0, but it’s now deprecated, and you should use ng-template:

Here we have defined a template, displaying a simple div. Alone, it does not have much use, as the browser will not display it. But if we add one 'template' element in a view, then Angular can use its content. The structural directives have the ability to do simple actions with this content, like displaying it or not, repeating it, etc.

Let’s see which directives are available!

Two other directives can be useful when writing a template, but they are not structural directives like the ones we just saw. These directives are standard directives.

Every syntax we have seen has a longer equivalent called the canonical syntax. This is mainly useful if your server side templating system is having trouble with the [] or () syntax, or if you really can’t bear to use [], (), *…​

If you want to declare a property binding, you can do:

or, using the canonical syntax:

For event binding, you can do:

or, using the canonical syntax:

And for local variables, you can use ref-:

instead of the shorter form:

The Angular templating system gives us a powerful syntax to express the dynamic part of our HTML. It allows to express data and property binding, event binding and templating concerns, in a clear way, each with their own symbols:

It provides a way to interact with standard Web Components like no other framework does. As there is no ambiguity between the various meanings, we will see our tools and IDEs gradually improve to give us meaningful warnings on what we are writing in our templates.

All these symbols are shorter versions of their canonical counterparts, which you can also use if you wish.

It takes some time to be fluent in this syntax, but you will soon be up to speed, and then it’s easy to read and write.

Let’s go through a complete example before moving on.

I want to write a PoniesComponent component, displaying a list of ponies. Each pony should be represented by a PonyComponent component, but we haven’t seen yet how to pass parameters to a component. So, for now, we are going to display a simple list. The list should be displayed only if it’s not empty, and I’d like to have some color for the even lines of my list. Finally, I want to be able to refresh the list with a button click.

Ready?

We start to write our component, in its own file:

You can add it to the PonyRacerAppComponent component we wrote in the previous chapter to test it. You will have to import it, add it to the directives and insert the tag <ns-ponies></ns-ponies> in the template.

Our new component has a list of ponies:

We are going to display this list, using NgFor:

One thing is missing, the refresh button:

And of course, a touch of color to finish, with the use of [style.color] and the isEven exported variable:

As you can see, we have used all the range of the templating syntax, and we have a perfectly working component. Our data are still hard-coded though: soon, we are going to see how to use a service to fetch them! This implies to learn about dependency injection first, so that we can use the HTTP service!

Dependency injection is a well-known design pattern. Let’s take a component of our application. This component may need some features offered by other parts of our app (let’s say a service). That’s what we call a dependency. Instead of letting the component create its dependencies, the idea is to let the framework create them, and provide them to the component. That is known as "inversion of control".

It has several interesting features:

It’s a concept vastly used on the server side, but AngularJS 1.x was one of the first to use it on the frontend side.

To be able to use dependency injection, we need a few things:

The framework does the rest of the job. When we declare a dependency in a component, it will look into the registry if it can find it, will get the instance of the dependency or create one, and actually inject it in our component.

A dependency can be a service provided by Angular, or a service we have written ourselves.

Let’s take an example with an ApiService service, already written by one of your colleague. Since he’s the lazy guy of the team, he just wrote a class with a method named get returning an empty array, but you can already guess that the service will be used to communicate with a backend API.

Using TypeScript, it’s easy to declare a dependency for our component or service, we just have to use the type system.

Let’s say we want to write a RaceService that would use the ApiService:

Angular will fetch the ApiService service for us and inject it into our constructor. When RaceService is needed, the constructor will be called, and we will have an apiService field referencing the ApiService service.

Now, we can add a method list() to our service, which will call our backend using the ApiService service:

To inform Angular that this service has some dependencies itself, we need to add a class decorator: @Injectable():

As we are using the ApiService, we need to "register" it, so as to make it available for injection.

An easy way to do this is to use the providers attribute of the @NgModule decorator we saw earlier:

Now, if we want to make our RaceService available for injection in other services or components, we have to register it too:

And we’re done!

We can use our new service wherever we want. Let’s test it in the PonyRacerAppComponent component:

As our lazy colleague returned an empty array in the get method of ApiService, you should get nothing if you try to call the list() method.

Maybe we can do something about it…​

I’ll come back to the testability advantages brought by dependency injection in a following chapter, but we can have a look at the configuration problem. Here we are calling a backend that does not exist. Maybe the backend team is not ready yet, or you want to do it later. In any case, we would like to use some fake data.

DI provides a nice way to do this. Let’s go back to the registration part:

We can represent the relations between component and services like this, where the arrows mean depends on:

In fact, what we wrote was the short form of:

We are telling the Injector that we want to create a link between a token (the type RaceService) and the class RaceService. The Injector is a service which keeps track of the injectable components by maintaining a registry and is actually injecting them when needed. The registry is a map that associates keys, called tokens, with classes. The tokens are not necessarily strings, unlike in many dependency injection frameworks. They can be anything, like Type references, for example. And that will usually be the case.

Since, in our example, the token and the class to inject are the same, you can write the same thing in the shorter form:

The token has to uniquely identify the dependency.

This injector is returned by the bootstrapModule promise, so we can play with it:

The interesting part is in the playWithInjector function.

As you can see, we can ask the injector for a dependency with the get method and a token. As I have declared the RaceService twice, with two different tokens, we have two providers. The injector will create an instance of RaceService the first time it is asked to for a specific token, and then returns the same instance for this token every time. It will do the same for each provider, so here we will actually have two instances of RaceService in our app, one for each token.

However, you will not use the token very often, or even at all. In TypeScript, you rely on the types to get the job done, so the token is a Type reference, usually bound to the corresponding class. If you want to use another token, you have to use the decorator @Inject(): see the last part of this chapter for more information about this.

This whole example was just to point out a few things:

The fact that the instance returned is created on the first call and then always the same is also a well-known design pattern: it’s called a singleton. This is really useful, as you can share information between components using a service, and you will be sure they share the same service instance.

Now, back to our fake RaceService problem. I can write a new class, doing the same job as RaceService but returning hardcoded data:

We can use the provider declaration to replace RaceService with our FakeRaceService:

If you restart your app, you will see that there we have one race this time, because our app is using the fake service instead of the first one!

Now we have a relation like this:

That can be really useful when you test your app manually or, as we will soon see, when you are writing automated tests.

In our example, we might want to use FakeRaceService when we are developing our app, and use the real RaceService when we are in production. You can change it manually of course, but you can also use another type of provider: useFactory.

In this example, we are using useFactory instead of useClass. A factory is a function with one job, creating an instance. Our example tests a constant and returns the fake service or the real service.

But wait, if we switch back to the real service, as we are using new to create the RaceService, it will not have its ApiService dependency instantiated! Right, if we want to make this example work, we have to pass an ApiService instance to the constructor call. Good news: useFactory can be used with another property named deps, where you can specify an array of dependencies:

Hooray!

Of course, this example is just to demonstrate the use of useFactory and its dependencies. You could, and should, write:

Declaring a constant for IS_PROD is really bothering: maybe we can use dependency injection too? I’m pushing things a bit as you can see :) You don’t necessarily need to force all things in DI, but this is just to show you another provider type: useValue.

One last crucial thing to understand in Angular: there are several injectors in your app. In fact, there is one injector per component, and this injector inherits from the injector of its parent.

Let’s say we have an app looking like:

We have a module AppModule with a root component PonyRacerAppComponent, with a child component RacesComponent.

When we bootstrap the app, we create the root injector for the module. Then, every component will create its own injector, inheriting its parent one.

It means that when we are declaring a dependency in a component, Angular will begin its search in the current injector. If it finds the dependency, perfect, it returns it. If not, it will do the same in the parent injector, and again, until it finds the dependency. If it doesn’t, it will throw an exception.

From this, we can deduce two things:

The @Component decorator can take another configuration option, called providers. This providers attribute can take an array with a list of dependencies, as we did for the providers attribute of @NgModule.

We can imagine a RacesComponent that would declare its own RaceService provider:

In this component, the provider with the token RaceService will always give an instance of FakeRaceService, whatever was defined in the root injector. It’s really useful if you want to have a different instance of a service for a given component, or if you want to have perfectly encapsulated components that declare everything they need.

Here we have:

The injection will then be resolved as:

As a rule of thumb, if only one component needs to have access to a service, it’s a good idea to only provide this service in the component’s injector, using the providers attribute. If the dependency can be used by the whole app, declare it in the root module.

If you want to use a token and not rely on TypeScript types, you will have to add a decorator for each dependency you want to inject. The decorator is @Inject() and receives the token of the dependency you want to inject. The same RaceService can be written as follow to use an ApiService service:

To make the decorators work in this example without TypeScript, you’ll have to use babel with the preset es2015 and the plugins angular2-annotations and syntax-decorators.

The core framework provides very few services, and those you will use in your apps are even scarcer: actually there are just two for now :).

One question that pops up frequently is how can I change the title of my page? Easy! There is a Title service you can inject and it offers a getter and a setter method:

The service will automatically create the title element in the head if needed and correctly set the value for you!

The other service is slightly similar: it allows to get or update the "meta" values of the page.

That’s really simple. Just build a class, and you’re done!

Just like in AngularJS 1.x, a service is a singleton, so the same, unique instance of the class will be injected everywhere. It thus makes a service a great candidate to share state between several unrelated components!

If your service has some dependencies itself, then you need to add the @Injectable() decorator on it. Without this decorator, the framework won’t do the dependency injection.

Our RacesService probably fetches the races from a REST API instead of returning the same list every time. To perform an HTTP request, the framework provides the Http service. Don’t worry, we’ll soon see how it works.

Our service has a dependency on Http to fetch the races, so we need to add a constructor with the Http service as an argument, and add the @Injectable() decorator on the class.

Then you have to add it to the providers attribute of a component, or, more realistically, to the providers of your root module:

Sometimes the raw data is not what we want to display in the view. We often want to transform them, filter them, limit their number, etc. AngularJS 1.x had a very handy feature to do this, very badly named 'filters'. Lessons have been learned and now these data transformers have a meaningful name! Nah, I’m just kidding, they are called 'pipes' :).

A pipe can be used either in HTML or in your applicative code. Let’s take an example and see how we can use it.

A pipe that is not really useful in a production app, but very handy when you are debugging your app, is JsonPipe. Basically, this pipe applies JSON.stringify() to your data. If you have some data in your component, an array of ponies called ponies, for example, and you want to quickly see what’s inside, you may want to try something like:

Tough luck, it’s going to display [object Object]…​

But JsonPipe is here to rescue us. You can use it in your HTML, in any expression:

And it will display the JSON representation of your object:

You can see where the name 'pipe' is coming from. To use a pipe, you have to add a pipe (|) character after your data, and then the name of the pipe you want to use. The expression is evaluated and the result goes through the pipe. It’s possible to chain several pipes, one after another, like:

We’ll come back to the slice pipe, but you can see that we are chaining the slice pipe and then the json one.

You can use it in an interpolation expression or in a property expression, but not in an event statement.

You can also use it in your code, via dependency injection:

But beware: the pipe must be added to the providers of your @NgModule (or @Component) in order to use it that way.

As this will be the same for every pipe, I will now just show you the HTML examples using interpolation.

If you want to display just a part of a list, slice is your friend. It works like the slice method in JavaScript, and takes two arguments: a start index and, optionally, an end index.

To pass an argument to a pipe, you have to add a colon :, then the first argument, then possibly, another colon and the second argument etc.

This example will display the first two elements of my list of ponies.

slice works with arrays and strings, so you can also truncate a string:

and that will display only 'Ninja'.

You can give the slice pipe only one index n, and it will take the elements from n to the end.

If you give it a negative integer, it will take the n last elements.

As we saw, you can also give the pipe an end index: it will take the elements until this index. If this index is negative, it will take the elements until the index, but starting from the end.

As you can use slice in any expression, you can use it even with NgFor:

The component will create only two div elements here, for the first two ponies, as we have applied the slice pipe to the collection.

The pipe argument can of course be a dynamic value:

You can use this to create a dynamic display where your user chooses how many elements she/he wants to see.

Note that it’s also possible to store the result of the slice in a variable, using the as syntax introduced in 4.0:

As its name makes it clear enough, this pipe transforms a string into its uppercase version:

The counterpart of the previous one, this pipe transforms a string into its lowercase version:

Angular 4 introduced a new titlecase pipe. It capitalizes the first letter of all words:

This pipe allows to format a number.

It takes one parameter, a string, formatted as {integerDigits}.{minFractionDigits}-{maxFractionDigits}, but every part is optional. Each part indicates:

A few examples, starting with what we have with no pipe:

Using the number pipe will group the integer part, even with no digits required:

The integerDigits parameter will left-pad the integer part with zeros if needed:

The minFractionDigits is the minimum size of the decimal part, so it will pad zeros on the right until reached:

The maxFractionDigits is the maximum size of the decimal part. You have to specify a minFractionDigits, even at 0, if you want to use it. If the number has more decimals than that, then it is rounded:

Based on the same principle as number, percent allows to display…​ a percentage!

As you can imagine, this pipe allows to format an amount of money in the currency you want. You have to give it at least one parameter:

The date pipe formats a date value to a string of the desired format. The date can be a Date object or a number of milliseconds. The format specified can be either a pattern like 'dd/MM/yyyy', 'MM-yy' or one of the predefined symbolic names available like 'short', 'longDate', etc.:

Of course, you can also display the time portion of the date:

The async pipe allows data obtained asynchronously to be displayed. Under the hood, it uses PromisePipe or ObservablePipe depending if your async data comes from a Promise or an Observable. I hope you now know what a Promise is (otherwise go back to the ES6 chapter), and we’ll come back to Observable quickly.

The async pipe returns an empty string until the data is finally available (i.e. until the promise is resolved, in case of a promise). Once resolved, the resolved value is returned. More importantly, it triggers a change detection check once the data is available.

The following example uses a Promise:

You can see the async pipe is applied to the variable asyncGreeting. This one is a promise, resolved after 1 second. Once the promise is resolved, our browser will display:

Even more interesting, if the source is an Observable, then the pipe will do the unsubscribe part itself when the component is destroyed (for example when the user navigates to another component).

And to avoid multiple subscriptions to your Observable or calling your promise multiple times, you can store the result of the call with as (since 4.0):

Of course, you can also create your own pipes. That’s sometimes very useful. In AngularJS 1.x, we often used custom filters. For example, we built one to display how much time elapsed since an action the user did (like 12 seconds ago or 3 days ago) in several of our apps. Let’s see how we would do this in Angular!

First we need to create a new class. It should implement the PipeTransform interface, which forces us to have a transform() method, the one doing the heavy lifting.

Does not sound too hard, let’s give it a try!

We are going to use Moment.js fromNow function to display how much time has elapsed since the date.

You can install Moment.js using NPM if you want:

And add it to our SystemJS configuration:

The typings for Moment are already included in the NPM dependency, so the compiler should be happy without us doing anything.

Now, we need to register the pipe in our app. For this, there is a special decorator we can use: @Pipe.

The chosen name will be the one allowing to use the pipe in the template.

To use the pipe in a template, the last thing you need to do is to add the pipe to the declarations of your @NgModule.

You may have heard of reactive or functional reactive programming lately. It has become quite popular in several languages platforms, like in .Net with the Reactive Extensions library, which is now available in pretty much every language (RxJava, RxJS, etc.).

Reactive programming is not really new. It is a way to build an app using events and reacting to them (hence the name). The events can be composed, filtered, grouped, etc. using functions like map, filter, etc. That’s why you sometimes find the terms "functional reactive programming". But, to be accurate, reactive programming is not really functional programming, as it does not necessarily include the concepts of immutability, the lack of side-effects etc. Reacting on events is something you may have done:

In reactive programming, all data coming in will be in a stream. These streams can be listened to, modified of course (filtered, merged…​), and can even become a new stream that can be listened to. This technique allows for fairly decoupled programs: you don’t have to worry much about the consequences of your method call, you just raise an event, and every part of your app interested in this business will react accordingly. And maybe one of these parts will raise an event also, etc.

Now, why am I telling you about that? What does it have to do with Angular?

Well, Angular is built using reactive programming, and we will use this technique for some parts as well. Reacting on a HTTP request? Reactive programming. Spawning a custom event for our component? Reactive programming. Dealing with value changes in our forms? Reactive programming.

So let’s focus on this topic for a few minutes. Nothing hard to handle, but it’s better to have a clear mind on this.

In reactive programming, everything is a stream. A stream is an ordered sequence of events. These events represent values (look, another value!), errors (that went bad) or completion events (ok, I’m done). All these are pushed from the data producer to the consumer. As a developer, your job will be to subscribe to these streams, i.e. defining a listener capable of handling the three possibilities. Such a listener is called an observer, and the stream, an observable. These terms were coined a long time ago, as it is a well-known design pattern: the observer pattern.

They are different from promises, even if they look a bit similar, as they both handle asynchronous values. But an observer is not a one-time thing like a promise: it will continue to listen until it receives a 'completion' event.

For now, observables aren’t part of the official ECMAScript specification, but they might be part of a future version, as there is an effort done to standardize it.

Observables are very close to arrays. An array is a collection of values, like an observable. An observable only adds the concept of values over time: in an array, you have all the values at once, while the values will come over time in an observable, maybe every few minutes.

The most popular reactive programming library in the JavaScript ecosystem is RxJS. And that’s the one that Angular relies on and lets us use.

So let’s have a look.

Every observable, just like every array, can be transformed using functions you may have already encountered:

So, if you take an array of numbers and want to multiply each by 2, filter those under 5, and print them, you can do:

RxJS let us build an observable from an array. And, as you can see, we can do the exact same thing:

But an observable is more than a collection. It is an asynchronous collection, where the events arrive over time. A good example is browser events. They will happen over time, so they are a good candidate to use an observable. Here is an example using jQuery:

You can build observables from AJAX requests, browser events, Web sockets responses, a promise, whatever you can think of. And from a function of course:

Observable.create takes a function that will emit events on the observer given as parameter. Here it simply emits one event for the demonstration.

You can also handle errors, because your observable may go wrong. The subscribe method can take another callback, one designed to handle errors.

Here the map method throws an exception, so the second handler of the subscribe method will log it.

Once the observable is done, it will emit a completion event that you can catch with a third handler. Here, the range method we are using to create the events will iterate from 1 to 5 and then emit the 'completed' signal:

And you can do many, many things with an observable:

We would need a whole book to go through it all! If you want to go further, have a look at the Rx Book. It contains the best introduction I’ve found on the subject. And if you want to have a good visual representation of what each function does, go to rxmarbles.com.

Now let’s have a look at how we will use observables in Angular.

Angular uses RxJS, and it allows us to use it too. The framework provides an adapter around the Observable object: EventEmitter. The EventEmitter has a method subscribe() to react to events and this method can receive three parameters:

The EventEmitter can emit an event by calling the emit() method.

Note that the subscribe method returns a subscription object, with a method unsubscribe to…​ unsubscribe.

Now that we know a little bit more about reactive programming, and the EventEmitter, let’s see how Angular uses it.

So far, we have seen some small components. And of course, you can feel that, as they are the backbone of our apps, they can be more complex than what we have seen. How do we pass data? How do we manage the lifecycle of our component? What are the good practices to build these things?

Directives: What do they do? Do they do things? Let’s find out!

A directive is very much like a component, except it does not have a template. In fact, the Component class inherits from the Directive class in the framework.

So it makes sense to start by studying directives, as everything we will see regarding directives also applies to components. We will look into the configuration options you are most likely to use. The more advanced ones are in a later chapter, ready for you when you master the basics.

As for a component, your directive will be annotated with a decorator, but instead of @Component, it will be @Directive.

Directives are very small pieces. You can think of them as decorators for your HTML: they will attach a behavior to elements in the DOM. You can have multiple directives on the same element.

A directive must have a CSS selector, which indicates to the framework where to activate it in our template.

A component is not really different from a directive: it just has two more optional attributes and must have an associated view. It does not bring a lot of new attributes compared to the directive.

If you use the Native option, you’re telling Angular to use the Shadow DOM of your browser to take care of the encapsulation. The Shadow DOM is a part of the rather new Web Component specification. This specification allows to create elements in a special DOM, which is perfectly encapsulated. With this strategy, if we look at the generated DOM with our browser’s inspector, we’ll see:

You can spot the #shadow-root (open) that Chrome will display in the inspector: that’s because our component has been included in a Shadow DOM element! And we can also see that the style was added at the top of our component’s content.

With the Native strategy, you are sure that your component’s styles are not "bleeding" into your child components. If we have another component inside the PonyComponent, it can also define its own red CSS class with a different style: you are sure that the correct one will be used, with no interaction between each others!

But remember, Shadow DOM is a rather new specification, so it’s not available in every browser. You can check the availability on the awesome website caniuse.com. So be careful when you use it in your apps!

As said earlier, this is the default strategy. And the reason is really simple: it emulates (hence the name) the Native strategy, but without using the Shadow DOM. So it’s safe to use everywhere, and will have the same behavior.

To achieve that, Angular will take the CSS defined for the component, and inline it inside the <head> element of the page (and not in each component as we saw for the Native strategy). But before inlining it, it’s going to rewrite the CSS selector, to append a unique attribute identifier. This unique attribute is then added to all the elements of our component’s template! That way the style will only apply to our component. The same example, would now give:

The red class selector has been rewritten to .red[_ngcontent-dvb-3], so it will only apply on elements that have both the class red and the attribute _ngcontent-dvb-3. You can see that this attribute has also been added to our div automatically, so that works perfectly. The <ns-pony> element also has a few attributes: _ngcontent-dvb-2 which is the unique identifier generated for its parent, and _nghost-dvb-3 which is a unique identifier for the host element itself. Yes, we can also add styles that apply on the host element, as we’ll see shortly.

This strategy is not doing any encapsulation. The styles will be inlined at the top of the page (as for the Emulated strategy), but not rewritten. They then behave like "normal" styles, cascading into children.

A special CSS selector exists to style only the host element. It is called :host, and it comes from the Web Component specification:

It will be kept as is for the Native strategy and rewritten into [_nghost-xxx] if you use Emulated.

To conclude, you don’t have to do much to have perfectly encapsulated styles, because the Emulated strategy takes care of this business for us. You can switch the strategy to use the Native one if you target only specific browsers, or None if you don’t want to encapsulate styles. This strategy can be tweaked per component, or globally for your whole app in the root module.

I love automated testing. My professional life revolves around the test progress bar going green in my IDE, patting me in the back for doing my job properly. And I hope you do care about tests too, as they are the only safety net we have when we write code. Nothing is more tedious than manually testing code.

Angular does a great job to let us easily write tests. So did AngularJS 1.x, and that’s partly why I loved using it. As in AngularJS 1.x, we can write two types of tests:

The first ones are there to assert a small unit of code (a component, a service, a pipe…​) works correctly in isolation, i.e. without considering its dependencies. Writing such a unit test requires to execute each of the component/service/pipe methods, and check that the outputs are what we expected regarding the inputs we fed it. We can also check that the dependencies used by this unit are correctly called, for example we can check that a service will do the correct HTTP request.

We can also write end-to-end tests. Their purpose is to emulate a real user interacting with your app, by starting a real instance and then driving the browser to enter values in inputs, click on buttons, etc. We’ll then check that the rendered page is in the state we expect, that the URL is correct, whatever you can think of.

We’re going to cover all this, but let’s begin with the unit test part.

As we saw earlier, unit tests are there to check a small unit of code in isolation. These tests can only assert a small part of your app works as intended, but they have several advantages:

One of the core concept of unit testing is isolation: we don’t want our test to be biased by its dependencies. So we usually use "mock" objects as dependencies. These are fake objects that we create just for testing purpose.

To do this, we are going to rely on a few tools. First we need a library to write tests. One of the most popular (if not the most popular) is Jasmine, so we are going to use it!

Being able to declare the dependencies with the test module has another use. We can without too much trouble declare a fake service as a dependency instead of a real one.

For the sake of the example, let’s say that my RaceService uses the local storage to store the races, with a key 'races'. Your colleagues have developed a service called LocalStorageService that deals with the JSON serialization, etc. that our RaceService uses. The list() method looks like:

Now, we don’t really want to test the LocalStorageService service, we just want to test our RaceService. That can easily be done by leveraging the dependency injection system to give a fake LocalStorageService:

to RaceService in our test, using provide:

Great! But I’m not completely satisfied with this test. Creating a fake service by hand is tedious, and Jasmine can help us spy on the service and replace its implementation by a fake one. It also allows to verify that the get() method has been called with the proper key 'races'.

The next step after testing a simple service is to test a component. A component test is slightly different because we have to create the component. We can’t rely on the dependency injection system to give us an instance of the component to test (you may have noticed by now that components are not injectable in other components :) ).

Let’s start by writing a component to test. Why not our PonyComponent component? It takes a pony as an input and emits an event ponyClicked when the component is clicked.

It comes with a fairly simple template: an image with a dynamic source depending on the pony color, and a click handler.

To test such a component, you first need to create an instance. To do this, we can also use TestBed. This class comes with a utility method, named createComponent, to create a component. The method returns a ComponentFixture, a representation of our component. Note that to create a component, it must be known from the test module, so we need to add it to the declarations attribute:

Here, we follow the "Given/When/Then" pattern to write the unit test. You’ll find a whole literature on the subject, but it boils down to:

We can also test if the component really emits an event:

Let’s have a look at another component:

and its test:

Here we query all the directives of type PonyComponent and test if the first pony is correctly initialized.

You can get the components inside your component with children or query them with query() and queryAll(). These methods take a predicate as argument that can be either By.css or By.directive. That’s what we do to get the ponies displayed, as they are instances of PonyComponent. Keep in mind that this is different from a DOM query using querySelector(): it will only find the elements handled by Angular, and will return a ComponentFixture, not a DOM element (so you’ll have access to the componentInstance of the result, for example).

When testing a component, we sometimes want to create a parent component that uses it. And if there are several use cases, we’ll have to create several parent components just to try different inputs for example.

Hopefully, when we are in a test, we can modify any component to reuse it in different tests, by overriding its template.

To do this, the TestBed gives an overrideComponent() method, to call before the createComponent() one:

As you can see, the method takes two arguments:

That means you can modify the template of the component you are testing, or one of its children (to replace a component with a big template by a dumb one).

template is not the only metadata available, you can also use:

As replacing the template is the most common use-case, Angular 4 introduced an overrideTemplate() method:

Now you’re ready to test your app!

End-to-end tests are the other type of tests we can run. An end-to-end test consists in really launching your app in a browser and emulating a user interacting with it (clicking on buttons, filling forms, etc.). They have the advantage of really testing the application as a whole, but:

As you may guess, you don’t have to choose between unit tests and e2e tests: you will combine both to have a great coverage and some warranties that your complete application runs as intended.

E2e tests rely on a tool called Protractor. It’s identical to the tool we used in AngularJS 1.x for the same purpose. And the great news is that it works both with AngularJS 1.x and Angular!

You will write your test suite using Jasmine like in the unit tests, but you will use the Protractor API to interact with your app.

A simple test would look like this:

Protractor gives us a browser object, with a few utility methods like get() to go to a page. Then you have element.all() to select all the elements matching a predicate. This predicate often relies on by and its various methods (by.css() to do a CSS query, by.id() to retrieve an element by id, etc.). element.all() will return a promise, with a special method count() used in the test above.

$('h1') is a shortcut, equivalent of writing element(by.css('h1')). It will fetch the first element matching the CSS query. You can use several methods on the promise returned by $(), like getText() and getAttribute() to retrieve information, or methods like click() and sendKeys() to act on this element.

These tests can be quite long to write and debug (much more than unit tests), but they are really useful. You can do all sorts of great things with them, like testing several browsers, do a screenshot every time a test fails, etc.

With unit tests and e2e tests, you have the keys to build a robust and maintainable application!

The Http module offers a service called HttpClient that you can inject in any constructor. As the service is coming from another module, you have to manually make it available to your component or service. To do so, import the HttpModule into the root module:

Once this is done, you can inject the HttpClient service wherever you need it:

By default, the HttpClient service will do AJAX request using XMLHttpRequest.

It offers several methods, matching the most common HTTP verbs:

If you used the $http service in AngularJS 1.x, you might remember that it heavily relied on Promises. In Angular, however, all these methods return an Observable object.

A few advantages come with the use of Observables for HttpClient like the ability to cancel requests, to retry, to easily compose them, etc.

Let’s start by fetching the races registered in PonyRacer. We’ll assume that a backend is already up and running, providing a RESTful API. To fetch the races, we’ll send a GET request to a URL like 'http://backend.url/api/races'.

Usually, the base URL of your HTTP calls will be stored in a variable or a service, that you can easily configure depending on your environment. Or, if the REST API is served by the same server as the Angular application, you can simply use a relative URL: '/api/races'.

Using the HttpClient service, such a request is straightforward:

This returns an Observable, to which you can subscribe to receive the response.

The response body is the most interesting part, and it is directly emitted by the Observable:

Of course, you can also have access to the full HTTP response. The object returned is then an HttpResponse object, with a few fields like the status code, headers, etc.

The observable will throw an error if the response status is different from 2xx or 3xx, and the error is then of type HttpErrorResponse.

Sending data is fairly easy too. Just call the post() method, with the URL and the object to post:

I won’t show you the other methods, I’m sure you get the idea.

This kind of work will usually be done in a dedicated service. I tend to create a service, like RaceService, where all the job is done. Then, my component just needs to subscribe to my service method, without knowing what’s going on under the hood.

You can also leverage the power of RxJS to retry a failed request a few times, for example.

Of course, you can tune your requests more finely. Every method takes an options object as an optional parameter, where you can configure your request. A few options are really useful and you can override everything in the request.

params represents the URL search parameters (also known as the query string) to add to the URL.

The headers option is often useful to add a few custom headers to your request. It happens to be necessary for some authentication techniques like JSON Web Token for example:

To let you access their API without being blocked by the Same Origin Policy enforced by web browsers, some web services don’t use CORS, but use JSONP (JSON with Padding).

The server will not return the JSON data directly, but wrap them in the function passed as a callback. The response comes back as a script, and scripts are not subject to the Same Origin Policy. Once loaded, you can access the JSON value contained in the response.

In addition to the classic HTTP methods, the HttpClient offers a jsonp method. All you have to do is specify the URL of the service you want to call, and add the name of the callback you want.

In the following example, we are fetching all the public repos from our Github organization using JSONP.

One of the reasons of the Http module rewrite was the introduction of interceptors. Interceptors are interesting when you want to…​ intercept requests or responses in your application.

For example, if you want to intercept every request to add a specific header to some of them, you can now write an interceptor like this one:

Note that you have to clone the request to update it (requests are immutable).

Then add your interceptor to the HTTP_INTERCEPTORS array via dependency injection:

Now every request will go through the interceptor, and receive the custom header if needed (here the requests to the Github API).

You can also intercept the response, which can be handy to handle errors in a generic way:

We now have a service calling an HTTP endpoint to fetch the races. How do we test it?

In a unit test, you don’t want to really call the HTTP server: that’s not what we are testing. We want to "fake" the HTTP call to return fake data. To do this, we can replace the dependency to the HttpClient service with a fake implementation by importing the HttpClientTestingModule. We can then use a class provided by the framework called HttpTestingController to fake the HTTP responses.

And you can also add a few assertions on the underlying HTTP request:

And we’re done!

Lets’s start using the router. It is an optional module, that is thus not included in the core framework.

As we saw for the other modules, you have to include it in your root module if you want to use it. But for that, we need a configuration to define the mapping between URLs and components. We can do this with a dedicated file, generally named like app.routes.ts, and containing an array representing the configuration:

Then we need to import the router module in our root module, initialized with the proper configuration:

As you can see, the Routes is an array of objects, each one being a…​ route. A route configuration is usually a pair of properties:

You may be wondering where the component will be inserted in the page, and that’s a good question. For a component to be included in our app, like the RacesComponent in the example above, we must use a special tag in the template of the primary component: <router-outlet>.

This is, of course, an Angular directive, whose only job is to act as a placeholder for the template of the component of the current route. Our app template would look like:

When we navigate, everything will stay (the header, main and footer here) and the component matching the current route will be inserted just after the RouterOutlet directive.

How can we navigate between the different components? Well, you can manually type the URL and reload the page, but that’s not very convenient. And we don’t want to use "classic" links, with <a href=""></a>". Indeed, clicking on that link makes the browser load the page at that URL, and restart the whole Angular application. But the goal of Angular is to avoid such page reloads: we want to create a Single Page Application. Of course, there is a solution built-in.

In a template, you can insert a link with the directive RouterLink pointing to the path you want to go to. We can use this directive because our root module imports the RouterModule, making all the exported directives of RouterModule available to the root module. The RouterLink directive can receive a constant representing the path you want to go to or an array of strings, representing the path and its params. For example in our RacesComponent template, if we want to navigate to the HomeComponent, we can imagine something like:

At runtime, the link href will be computed by the router and will point to /.

The RouterLink directive can be used with the RouterLinkActive directive which can set a CSS class automatically if the link points to the current route. This allows, for example, to style a menu item as selected when it points to the current page.

We can even get a reference on this directive, to know if the route is active, and use it in the template:

It’s also possible to navigate from the code, by using the Router service and its method navigate(). It’s often handy when you want to redirect your user after an action:

The method takes an array of parameters, with the path you want to navigate to as the first element.

It is also possible to have parameters in the URL, and it’s really useful to define dynamic URLs. For example, we want to display a detail page for a pony, with a meaningful URL for this page, like ponies/id-of-the-pony-/name-of-the-pony.

To do so, let’s define a route in the configuration with one (or several) dynamic parameter.

We can then define dynamic links with routerLink:

Of course, the target component needs to access those parameters to be able to load and display the pony with the given identifier. To get the value of the parameters, the router provides a service, that you can of course inject in the component, named ActivatedRoute. This object can be used inside ngOnInit, and has a very useful field: snapshot. This field has all the parameters of the URL in paramMap!

This hook is also a good place to do the initialization work of the component as you can see.

As you may have spotted, we are using snapshot. Is there a non snapshot version? Yes there is. And it provides a way to subscribe to parameter changes, with, you guessed it, an observable. This observable is called paramMap.

Here we subscribe to the observable offered by ActivatedRoute. Now, every time the URL will change from /ponies/1 to /ponies/2 for example, the paramMap observable will emit an event, and we’ll fetch the correct pony to display on screen.

Note that instead of subscribing to the result of the PonyService inside the subscribe of the params update, we can use the more elegant switchMap operator:

What you just learnt should cover your basic routing needs. But the router goes well beyond this and offers many additional features. Covering them all in details is quite a big task, and you can feel overwhelmed when trying to learn them all.

This section will try to present most of the additional features as concisely as possible, by explaining what they’re useful for. But it will not try covering every detail. If you really need an extensive coverage of the router features, there’s a whole book available for that, written by the main contributor to the Angular router, Victor Savkin.

Forms have always been extra polished in Angular. That’s one of the features that was the most demoed in 1.x, and, as pretty much every app has forms, that won the hearts of a lot of developers.

Forms are hard: you have to validate the inputs of your user, display errors, you can have fields required or not, or depending on another field, you want to react on some field changes, etc. We also need to test these forms, and that was impossible to achieve with a unit-test in AngularJS 1.x. It was only feasible with an end-to-end test, which can be slow.

In Angular, the same care has been applied to forms, and the framework gives us a nice way to write our forms. In fact, it gives us several ways!

You can either write your form using only directives in your template: that’s the "template-driven" way. From our experience, it shines when you have a simple form, with not much validation.

The other way is the "code-driven" way, where you will write a description of the form in your component, then use directives to bind this form to the inputs/textareas/selects in your template. It’s more verbose, but also more powerful, especially if you want to do add custom validation, or to generate dynamic forms.

Let’s go through the same use case twice, using each way, and see the differences.

We are going to write a simple form, to be able to register new users in our awesome PonyRacer app. We need a base component for each use case, let’s begin with this:

Nothing fancy: a component with a simple template containing a form. In the next minutes, we will build a form allowing to register a user with a username and a password.

For both methods, Angular will create a representation of our form.

In the "template-driven" way, it’s pretty much automatic: we just need to add the proper directives in the template and the framework takes care of the form representation creation.

In the "code-driven" way, we create this form representation manually, and then bind the form representation to the inputs using directives.

Behind the scenes, a form field, like an input or a select, is represented by a FormControl in Angular. It is the smallest part of a form, and it encapsulates the state of the field and its value.

A FormControl has several attributes:

It also offers some methods like hasError() to check if the control has a specific error.

So you can do something like this:

Note that you can pass an argument to the constructor, and that this argument will be the value.

These controls can be grouped in a FormGroup to represent a part of the form and have dedicated validation rules. The form itself is a group.

A FormGroup has the same properties as a FormControl, with a few differences:

It offers the same methods as FormControl like hasError(). It also has a method get() to retrieve a control in the group.

You can create one like this:

Let’s begin with a "template-driven" form!

With this method, we are going to use a bunch of directives in our form, and let the framework build the necessary FormControl and FormGroup instances. For example, the NgForm directive transforms the form element into its powerful Angular version - think of it as the difference between Bruce Wayne and Batman.

All the directives we need are included in the FormsModule module, so we need to import it in our root module.

FormsModule contains the directives for the "template-driven" way. We’ll see later that there exists another module, ReactiveFormsModule, in the same package @angular/forms, which is needed for the "code-driven" way.

Let’s add the submit button:

I added a button, and defined an event handler for ngSubmit on the form tag. The ngSubmit event is emitted by the NgForm directive when submit is triggered. It calls the register() method of our controller, which will be implemented later.

Last thing: our template will quickly grow, so let’s extract it to a dedicated file, using templateUrl:

In the "template-driven" way, you write your forms pretty much like in AngularJS 1.x, with a lot of things in your template and not many in your component.

In its simplest form, you just add ngModel directives to your form template and that’s all. The NgModel directive creates the FormControl for you, and the form automatically creates the FormGroup. Note that you have to give a name to the input, that will be used by the framework to create the FormGroup.

Now of course we need to do something for the submission, and to get hold of the user name and password. To achieve that, we can define a local variable and assign it with the NgForm object created by Angular for the form. Remember these from the Template chapter? Here, we are going to define a variable, userForm, referencing the form. We can do that because the form directive exports the NgForm directive instance, which has the same methods as the FormGroup class. We’ll see the exporting part in more details when we study how to build advanced directives.

Our register method is now called with the form value as the argument:

This is only one-way data-binding though. If you update the field, the model will be updated, but updating the model will not update your field value. But ngModel is more powerful than you think!

In AngularJS 1.x you had to build your forms mostly in your templates. Angular introduces an imperative way, which allows to construct the form programmatically rather than through a template.

Now we can handle forms directly in our code. It’s more verbose but more powerful.

To build a form in our component code, we’ll use the abstractions we talked about: FormControl and FormGroup.

With these basic elements we can build a form in our component. But instead of writing new FormControl() or new FormGroup(), we will use a helper class, FormBuilder, that we can inject:

The FormBuilder is a helper class, with a handful of methods to create controls and groups. Let’s start simple, and create a small form with two controls, a username and a password.

We created a form with two controls. You can see that each control is created with the value ''. That’s the same as using the helper method control() of the FormBuilder with this string as parameter, and the same as calling the new FormControl('') constructor: the string represents the initial value you want to display in your form. Here it is empty, so the inputs will be empty. But you can have a value here, of course, if you want to edit an existing entity for example. The helper method can also have other specific attributes, as we will see later.

We need to implement the register method. As we saw, the FormGroup object has a value attribute, so we can simply log its content with:

We now need to do some work in the template. We are going to use other directives than those we saw for the "template-driven" forms. These directives are in the ReactiveFormsModule that you have to import in your root module. Their names begin with form instead of ng as it was the case for the "template-driven" forms.

The form needs to be bound to our userForm object, thanks to the formGroup directive. Each input field is bound to a control, thanks to the formControlName directive:

We want to bind our component’s attribute userForm object to formGroup, so we use the bracket notation [formGroup]="userForm". Each input receives the formControlName directive with a string literal representing the control it is bound to. If you specify a name that does not exist, you will have an error. As we pass a value (and not an expression), we don’t put the [] around formControlName.

And we’re done: clicking on the submit button will log an object containing the username and the chosen password!

If you need to, you can update the value of a FormControl from your component, using setValue():

Validation is usually a big part of the form-building. Some fields are required, some depend on one another, some should be in a specific format, some should not have a value greater or lower than X, for example.

Let’s start by adding basic validation rules: all our fields are required.

Of course, our user should not be able to submit the form while there are still errors left, and these errors should be perfectly displayed.

If you try the examples, you will see that even if the fields are required, we can still submit our form. Maybe we can do something about that?

We know that we can easily disable a button using the disabled property, but we need to give it an expression reflecting the state of the current form.

Whatever way you choose to create your forms, Angular does another awesome job for us: it automatically adds and removes CSS classes on each field (and on the form) to allow us to add some visual style.

For example, a field will have the class ng-invalid if one of its validators fails, or ng-valid if all the validators succeed. That means you can easily add some style, like a nice red border around the fields failing the validation:

Another useful CSS class is ng-dirty which will be present if the user has changed the value. Its opposite is ng-pristine, present if the user never changed the value. I usually display the red border only when the user has changed the value at least once:

Finally, there is a last CSS class: ng-touched. It will be present if the user enters and leaves the field at least once (even if she/he did not changed the value). Its opposite is ng-untouched.

When you display a form for the first time, a field will usually have the CSS classes ng-pristine ng-untouched ng-invalid. Then, when the user enters and leaves the field, it switches to ng-pristine ng-touched ng-invalid. When the user changes the value, still for an invalid one, we’ll have ng-dirty ng-touched ng-invalid. And finally, when the value is valid: ng-dirty ng-touched ng-valid.

Pony races are an addictive game so it’s only allowed to register if you are over 18. And we want the user to enter the password twice, to be sure she/he hasn’t made a mistake.

How do we do this? We create a custom validator.

To do so, we just have to create a method that takes a FormControl, tests its value and returns an object with the errors or null, if the validation passes.

Our validation method is pretty easy: we take the value of the control, we build the date, check if the 18th birthday is before now and return an error with the key 'tooYoung' if not.

Now we need to include this validator.

Until now, we just had one group: the complete form. But we can declare groups inside a group. That’s very useful if you want to validate a group of fields together like an address, or, like in our example, if you want to check if the password and its confirmation match.

The solution is to use a code-driven form (that you can combine with a template-driven form if you want to, as we saw above).

First, create a new group, passwordForm with the two fields and add it in the group userForm:

As you can see, we have added a validator on the group, passwordMatch, that will be called every time one of the fields changes.

Let’s update the template to reflect the new form, using the formGroupName directive:

Voilà!

Last cool feature when using a code-driven form: you can easily react on value changes, using the observable valueChanges. Reactive programming FTW! For example, let’s say we want our password field to display a strength indicator. We want to compute the strength at every change of the password value:

Now we have a passwordStrength field in our component instance, that we can display to our user:

We are leveraging RxJS operators to add a few cool features:

RxJS can do tons of work for you: imagine coding yourself what we just did in two lines. It can also easily combine with HTTP work, as the Http service uses observables too.

Angular offers two ways to build a form:

This is maybe the most pragmatic approach: go with template-based and bidirectional binding if you like it, and as soon as you need access to form groups or form controls, for example to add custom validation or reactive behavior, then declare the ones you need in the component, and bind the inputs and divs to them using the appropriate directives.

The first step is to detect changes in the model. A change is always triggered by an event, coming either from the user directly (for example, a button click or an input in a form), or from a "system" event (an HTTP response, an asynchronous method execution after a timeout, etc.).

So, how does AngularJS 1.x know that an event has happened? That part is actually pretty simple: it forces us to use its directives, for example ng-click to react to a click event, or ng-model to observe changes to an input. It also forces us to use its services, for example $http for HTTP requests or $timeout to execute tasks asynchronously.

Using these directives and services allows the framework to be well informed about any event that has happened. That’s the first part of the magic! And that’s this first part which triggers the second one: the framework now has to analyze the changes made to the model, in order to decide which part of the DOM must be updated (and how).

To do that, in version 1.x, the framework maintains a list of watchers, all observing and reacting to changes in a specific part of the model. To simplify, a watcher is created for every dynamic expression used in the HTML templates. This can lead to several hundreds of watchers in a page.

These watchers are central to AngularJS 1.x: they are the memory of the framework, and are here to remember the state of the app.

Every time the framework detects an event (a user typing something in an input with an ng-model, an HTTP response, a timeout execution, etc.), it triggers what is called the digest cycle.

This digest cycle evaluates all the expressions stored in the watchers and compares their new value with their old value. If there is a change, then the framework knows that it has to update the DOM, so that the UI displays the new value instead of the old one. This technique is called dirty checking.

During this digest cycle, Angular is going over the whole list of watchers, and evaluates every watched expression. But there is a catch: it will execute this whole cycle again until the results are stable, i.e. until all the new values are equal to the old values.

Why does it do that? Because each time a change is detected in the value of a watched expression, a callback function is called. And this callback function can, in turn, modify the model, and thus change the value of one or several other watched expressions!

Let’s take a minimalistic example: a page with two fields that the user must fill: name and password. Let’s also say that the page displays a password strength indicator. A watcher is used to watch the value of the password, and recomputes its strength every time it changes.

After the first iteration of the digest cycle, once the user has entered the first letter of his/her password, we thus have this list of watchers:

The callback function of the watcher observing the user.password expression is then called, and it computes the new password strength: 3.

Angular doesn’t know anything about the changes that might have been done on the model, so it starts a second digest iteration to know if the model is stable.

The model isn’t stable: the value of passwordStrength has changed since the first iteration. So it starts another digest iteration.

This time, the model is stable. That’s only at that time that AngularJS 1.x is flushing the result to the DOM. So the digest cycle happens at least 2 times for every change in your application. The digest can iterate up to 10 times, but no more: after 10 iterations, if the results are not stable, the framework considers there is an infinite loop and throws an exception.

So my little drawing earlier is much more like:

And to insist: this is going on after each event. That means that if your user is entering 5 characters in the password field, the digest cycle will run 5 times, with 3 iterations every time, which leads to a total of 15 iterations.

In a real application, you can have several hundred watchers, and thus thousands of expression evaluations after every event!

Even if that sounds crazy, it works fine, because modern browsers are very fast, and there are ways to optimize a few things if necessary.

So let’s recap the two important points about AngularJS 1.x:

The magic in the framework can be split in two parts:

Now let’s see how Angular is working, and how it differs from AngularJS.

Angular is based on the same principles, but implements them in a different way. And we might even say, in a smarter way.

For the first part of the problem — triggering the change detection — the Angular team has built a small side-project named Zone.js. This project is not tied to Angular, because zones are a tool that can be useful in other projects. Zones are not a brand new concept either: they already exist in the Dart language (another Google project), for quite some time. They also have similarities with Domains in Node.js (now abandoned) or the ThreadLocals in Java.

But it’s probably the first time that zones are being used in JavaScript. No worries, we’ll discover them together.

In the previous chapter, we talked briefly about how the framework was generating a change detection function for each component.

This is a very interesting and particular point in Angular, which you don’t see in other frameworks: Angular, at the start of your application, will compile your templates and generate dynamic code for each component.

The HTML you write in your templates is never read by the browser directly. Instead, Angular generates a class for each component that represents exactly what you wrote in your template. This class is generated in a file with the ngfactory.js extension, and you can see it in your browser if you open the Sources tab in the console.

Let’s take an example, with our well-known PonyComponent. The template is mainly an image with a bound source property, and a legend with an interpolation.

When Angular compiles this, it first starts by parsing the template to generate what is called an Abstract Syntax Tree (AST). An AST is a tree representing the structure of the template, commonly used by compilers to represent such things. It is the result of the syntax analysis step of the compilation. This AST will then be used to generate the dynamic JavaScript code, a "view definition" per component (in our case View_PonyComponent). A view definition contains the nodes of the templates. Nodes can have various types, for example an element (elementDef), with its name and attributes, or a simple text node (textDef).

In fact, instead of generating the structure as a tree, the compiler generates a flat array (depth-first, with each node indicating how many children it has), for performance reasons:

With this representation, Angular is able to generate the DOM corresponding to our PonyComponent: it basically appends the corresponding HTMLElement to the DOM, for every element of the array.

But how does it handle the change detection? The view definition has in fact a last parameter: a change detection function.

This change detection function does basically what you would write by hand. It is called by the framework every time it needs to check if there is a change (see the previous chapter). It basically gets the values of the dynamic bits (the src attribute and the interpolation), and then calls a function of the framework with the view data, the index of the element to update and the new value. The checkBinding function has only one job: it compares the previous value stored for this element and if it changed, updates it, and replaces it with the new value.

This generated code is very fast and can be optimized by JS engines (see the part on monomorphism and inline caching in the previous chapter). On the other end, it takes some time to generate this code when the application starts. This is called the Just in Time (JiT) compilation.

To sum up, when you are using the JiT compilation: you write TypeScript code and HTML templates, you compile your TypeScript to JavaScript and send the JS and HTML to your users. At runtime, the HTML is then compiled to JS code too.

But could we generate this code before starting the application? And indeed we can, using a compiler that the Angular team wrote: the Ahead of Time (AoT) compiler. You can call it manually in your project (ngc), or if you are using the CLI (as you should), it is a simple flag to add when you build or serve the app:

The build will now use the Angular compiler to compile the templates to TypeScript files. To TypeScript? Yes, because it then allows to check that we didn’t make a mistake in our templates! The generated TypeScript code and our application code will then be compiled by TypeScript (ngc will call the TypeScript compiler immediatly), and if you made a mistake in a template, you’ll see an error:

The Angular compiler then generates this TypeScript code:

which raises an error in the TypeScript compilation:

This is great, because it means you can check all your templates before even running the application. Your future refactoring will be painless: if you rename a method or a property in a component, you’ll know straight away that the template must be updated, too, because it breaks the build.

It also means that this compilation may throw an error whereas your code can be fine in the Just in Time mode. For example, if you have a private property in your component used in your template, it will be fine in JiT mode (because JavaScript has no notion of private property), but will break in AoT mode (as the TypeScript code of the ngfactory generated needs to access the property). Right now, there is no really good source of documentation on the additional rules you must respect to be AoT-compliant, except this repository from Rangle.

Compiling your application before shipping to your users will also greatly speed up the start of the application, as the compilation will already be done!

To sum up, in AoT mode: you still write TypeScript and HTML, you compile the HTML to TypeScript and then all TypeScript code to JavaScript, and send this JS code to your users.

The downside will be the size of the JavaScript bundle you will ship to your users: the generated code is larger than the uncompiled templates. This is somewhat compensated by the fact that you don’t need to ship the Angular compiler to your users, as the templates are already compiled. And the compiler is a big piece of code, so this is a nice win. On a medium or large application, this generally doesn’t compensate the increase in size from the generated factories though. If you want to have all the perks of the AoT compilation AND a small bundle, you’ll need to dig into the lazy-loading feature we explained in the Router chapter.

If you want to dig this topic deeper, there is a great talk on the compiler at ng-conf 2017

To sum up what we learned in the chapter about Reactive Programming, an Observable represents a sequence of events to which we can subscribe.

This stream of events can happen at any time, and there can be only one event or ten thousands of them. But there is a distinction to understand between two kinds of Observables: cold ones and hot ones.

Cold observables will only emit events when they are subscribed to. You can think of it as watching a Youtube video: the video will only stream when you hit the "Play" button. For example, the observables returned by the Http class are cold observables: they will only trigger the request when you subscribe.

Hot observables are slightly different: they emit events from the moment they are created. You can think of them as live television: you turn on the TV and you land in the middle of a show, that can have started minutes or hours ago. The observable representing the valueChanges in a FormControl is also a hot observable. You will not receive the values emitted before the moment you subscribed, only the value from the moment you subscribe.

When you subscribe to an observable, you can pass three possible parameters:

The first one is pretty obvious. The observable is a stream of events and you define what to do if an event occurs.

The second one allows to handle a potential error. It’s not always necessary to pass this function. If the stream of events represents a stream of clicks, there are no possible errors that can occur, even if your user broke his finger (this joke is not mine, it’s from a great presentation from André Staltz on RxJS at NgEurope 2016). But in most cases, it is very useful to define an error handler. It allows to define what to do if you get an error response from the HTTP backend, for example.

One thing to understand about this: an error is a terminal event, the observable will not emit new events after it. So if it is important for you to continue to listen, you probably want to handle this properly (we’ll come back to this in a minute).

The third function you can pass allows to handle the completion: that’s because an observable can finish (your Youtube video is over for example). And sometimes you want to do something if the observable is over, like warning your user, or computing a value…​

In our Ponyracer app, a race is represented by an observable, emitting the positions of the ponies. When the race is over, the observable stops emitting events. Then we want to compute which pony won the race, change the UI to reflect that, etc.

But maybe the user won’t stay around until the end of the race. What happens then? The component will be destroyed. But, if we subscribed to an observable in that component before the destruction, then the next function will continue to do its job every time an event occurs. Even if the component is no longer displayed! That can lead to memory leaks and all sorts of trouble…​

So the best practice is to store the subscription returned by the subscribe function, and on the destruction of the component, call unsubscribe on this subscription (typically in the ngOnDestroy method). Wrap the unsubscribe in a check to test if the subscription is present (maybe the subscription is not initialize yet, and then you’ll have an error because the object will be undefined when you’ll call unsubscribe).

This general rule has a few exceptions. You don’t necessarily need to do this for observables that will only emit an event then complete, like an HTTP request. And you definitely don’t need to do this if you subscribe to one of the router observables, like the params observable: the router will clean up for you, yay!

Last, but not least, the async pipe. Angular provides a special pipe, called async. You can use it in your templates to directly subscribe to an observable.

It has a few advantages:

It also have a downside: you have to be careful when using this syntax multiple times in a template.

Let me illustrate the last point, in a RaceComponent, displaying the race properties:

This code sample assumes that the method raceService.get() returns an Observable emitting a RaceModel. We store this observable in a field named race (you’ll sometimes see the name race$ in blog posts, because other frameworks use that naming convention for variables of type Observable). Then we use the race observable in the template with the async pipe twice: once to display the name and once to display the date. The component’s code is quite elegant: you don’t have to manually subscribe to the observable.

But maybe you can spot the problem. We call twice the async pipe, which means that we subscribe twice to the observable. If the raceService.get() method performs an HTTP request to fetch the race details, this request will be performed twice!

A first solution would be to modify the observable to share it between the different subscribers. This can be achieved with the publishReplay operator for example:

But, even if that’s now correct and does not produce two different HTTP requests, I still don’t really like the template. Quite often, the component needs to access the race anyway for some presentation logic, and not only the template. And it has to handle errors, too. A subscription, or a do() and/or catch() operator in the component is often necessary anyway. So storing the race in a field is not a big burden, and makes the template code simpler.

Note that the 4.0 release introduced an as syntax that can solve the problem by subscribing only once and storing the result in a variable of the template:

This is quite elegant.

Another possible solution is to split our component in two: a smart one (responsible for the race fetching) and a dumb one (that just displays the race received in input).

That would look like:

This pattern can be useful in some parts of your application, but, like every pattern, you don’t have to use it everywhere. It’s sometimes not a big deal to have only one component that does both. Other times, you’ll want to extract a dumb component to reuse it in another part of your application for example, so two components will make sense.

We saw a few operators until then, but I’d like to take a moment to describe a few others in a step by step example. We are going to code a typeahead input. A typeahead allows your users to enter a text in an input, and then the application displays a few suggestions based on this text (like a Google search box).

A good typeahead has quite a few features:

All this can be done by hand, but it’s far from being trivial. But we’re in luck, Angular and RxJS combine nicely to solve this kind of problem!

First let’s see what a component like this would look like:

In the ngOnInit method, we can start by subscribing to the valueChanges observable exposed by the FormControl (check the chapter on forms if you need to refresh your memory).

Next we want to use this value to fetch the ponies matching the given input. Our PonyService has a method search that does exactly that! We can suppose that this method does an HTTP request behind the scenes to fetch the results from the server, so it returns an Observable<Array<PonyModel>>, an observable that emits arrays of ponies.

Let’s subscribe to this method to update the ponies field of our component:

OK, that works. But when I see something like this, it reminds me of Promises and nested then calls, that can be flattened. And indeed you can do the same with Observables, with the concatMap operator for example:

Wow, much more elegant! concatMap "flattens" our code. It replaces every event emitted by the source observable (i.e. the entered pony name) by the events emitted by the observable of ponies. But it’s not the perfect operator for this situation. As our search method performs an HTTP request per search, we can run into some troubles if a request is too slow. Our user might query n then ni, but the result might come back really slowly for n, and fast for ni. That means our code above will display the second results only after the first displayed, even if we don’t care about the first ones anymore! This could be tracked by hand, but that would be really cumbersome.

RxJS provides a super useful operator for this use-case: switchMap. Unlike concatMap, switchMap will only care about the last value emitted, and will discard the earlier values, so we’re sure that the results corresponding to an old input won’t be displayed.

OK, now let’s discard the queries that are less than three characters. Easy: we just have to use a filter operator!

We also don’t want to search immediately after a keystroke: we’d like to search only after the user stops typing for 400ms for example. Yep, you guessed it: there’s an operator for that, and it’s called debounceTime:

So now a user can enter a value, delete some character, add others and the query will only fire when 400ms have passed since the last keystroke. But what if the user enters "Rainbow", waits for 400ms (which will thus send a request), then enters "Rainbow Dash" and immediately removed the "Dash" to get back to "Rainbow"? That would send two subsequent requests for "Rainbow"! Maybe we can only trigger a request if the query is different than the last one? Of course we can, with distinctUntilChanged:

Last thing: we need to properly handle the errors. We know that the valueChanges will not emit any error, but our ponyService.search() observable might throw as it is dependent on the network. And the problem with observables is that an error will completely break the stream: so if one request blows, the whole typeahead will be down…​ We don’t want that, so let’s catch potential errors:

Quite nice, don’t you think? We now only trigger a search when the user enters a text with more then 3 characters and waits at least 400ms. We guarantee that we don’t trigger the same request twice, and that the results are always in sync with the request! All that in 5 lines of code. Good luck doing the same by hand without adding any issue…​

This is of course a really good use-case for RxJS, but the point is that it provides a lot of operators, with some gems hidden in it. It takes time to understand it, but it’s worth the trouble as it can be tremendously useful in your application.

Sometimes, sadly, you need to use libraries that produce events but not using an Observable. All hope is not lost, because you can of course create your own Observables, using, for example, the Observable.create(observer ⇒ {}) method.

The method passed as a parameter is called the subscribe function: it will be responsible for emitting events and errors, and to complete when done.

For example, if you want to create an Observable which emits 1, then 2, then completes, you could do:

Now we could subscribe to such an observable:

Now, let’s say I want to emit 'hello' every 2 seconds, and never complete. We could easily do this with some built-in operators, but we can try by hand, as a small example:

The callback function passed to Observable.create() can also return a function that will be called on the unsubscription. That’s really useful if you have some cleanup to do. Like us with our HelloService, because we’ll need to stop the setInterval when the observable will be unsubscribed.

The interval will not be created until the subscription, so we just created a cold observable.

I hope you enjoyed this small chapter on observables. They can also be use to sequence your HTTP requests, or to communicate between components (more on this soon). But you have now a good overview of what’s possible!

In the Template chapter, we talked about a nice feature called "local variables", allowing to get a reference to a DOM element in the template. For example, you can give the focus to an input with a button easily:

We also saw this same feature in the Forms chapter for example, when we wanted to grab a reference to a specific directive:

What if we need to have these references in our component code, and not only in the template? That where "view queries" enter the scene and can save the day!

For example, you may want to focus an input as soon as your component is displayed. To do so, we need to grab a reference to the input, using the ViewChild decorator.

We declare a field called loginInput, and we decorate it with ViewChild. This decorator needs a selector as parameter: here we use the local variable declared in our template. The decorator indicates to the framework that it needs to query the template to find an element with this local variable name. The field will be initialized with this element, of type ElementRef. This type has only one field, nativeElement, which is a reference on the underlying DOM element.

The example also showcases a nice use of the lifecycle method ngAfterViewInit. This method is called as soon as the view is created, so you are sure that the element you are waiting for is indeed present. If you try to do the same in ngOnInit, it won’t work. There is also another method called ngAfterViewChecked, which is called every time the view is checked (after each change detection).

If you wanted to have this feature in a lot of different components, you could create a directive for this, instead of duplicating the code in each component.

This directive does nothing yet, but it would be used like this in a template:

The directive needs to access its host element to give it the focus. That’s where ElementRef is interesting, as it can be injected in our directive:

And we’re done: using this directive will give the focus to its host element!

Let’s go back to our ViewChild decorator: it can also accept a type as a selector.

For example, in the Forms chapter, we saw that to submit a form in the template-driven way, you can use two-way binding, or you can grab a reference to the form and pass its value to the submit method:

But we can also use a ViewChild for this:

The cool thing with ViewChild is that it is a dynamic query: it will always be up to date with the template. If the element queried is destroyed, the field will be undefined.

This decorator also has a twin called ViewChildren. Unlike ViewChild which will get a reference to one field matching the selector (the first if there are several ones), ViewChildren will get a reference to all the fields. It returns a QueryList, a type with a few useful attributes:

Let’s say we have a RaceComponent displaying a list of PonyComponent, we can easily be notified every time a PonyComponent is added or removed:

QueryList has also a lot of methods available like toArray(), map(), filter(), find()…​

Another common thing that we usually need as developers is the ability to build UI components whose content will be dynamic.

For example, let’s say you want to build a "card" component using the Bootstrap 4 CSS framework. The template of such a card looks like this:

You can of course duplicate this HTML every time you need it in your application. But at this point of your read, you are probably thinking about building a component. Two parts are dynamic in the card (the title and the content), so this is probably what you will come up with:

And then use it like this:

This works perfectly. But looking more closely to your need, you realize that the content of the card can also be complex HTML, and not just text, which is supported by Bootstrap!

Of course, Angular has your back, and it’s easy to "pass" HTML to a child component, thanks to <ng-content>. That’s what we used to call "transclusion" in AngularJS 1.x.

ng-content is a special tag you can use in your templates to include HTML provided by the parent component:

And you can now use the component like this:

Later, you realize that the title can also be some complex HTML. Of course, there is a way to pass multiple contents to the card component, using multiple ng-content with a selector.

and use it like this:

This will produce the following result:

When you are using these ng-content tags, the projected content will not be queried by ViewChild or ViewChildren. For these contents, you have to use two other decorators: ContentChild and ContentChildren.

Let’s say you are building another UI component based on Bootstrap 4, this time a "tabs" component. The HTML must look like this according to the docs:

But we would like to offer a nice component to our team, something like:

We need an outer Tabs component, which must find out how many ns-tab directives are embedded inside the component template, iterate through each of them and generate the appropriate markup.

To do so, let’s start by creating a directive TabDirective:

The directive doesn’t do much: it only has an input to get the tab title. Note that we are using an element as the selector, ns-tab.

Now we need to build the TabsComponent:

As you can see, the template iterates through an array of tabs to generate an li element for each of them. But where does this tabs array come from? How can the component know about the two ns-tab directives embedded inside the ns-tabs component? That’s what the ContentChildren directive allows doing.

To grab the list of the tabs, we need to use ContentChildren, here with TabDirective. This gives us an iterable list of tabs, that you can use in an NgFor. As each element of this list is a TabDirective, we can then access the public property title, and display the tab’s title!

Note that if, for whatever reason, you had a template like this one:

Then the QueryList in TabComponent will only contain the first TabDirective. ContentChild and ContentChildren are indeed only looking for direct descendants, and will stop at the ns-tabgroup component.

If we want our component to still work with this, there is an option you can add to your decorator:

Now it finds all the TabDirective again!

The tabs field is a QueryList, so you can also subscribe to the changes, like we saw for ViewChildren. Once again, the QueryList is not accessible in the component constructor or even in ngOnInit. To be sure that the content can be queried (i.e. that the QueryList is properly populated), use the ngAfterContentInit lifecycle hook. You can also use the ngAfterContentChecked hook, which is called every time the content is checked.

When writing a directive, it can be fairly common to interact with the host element.

Let’s take a simple example: our customer wants to easily clear the content of some text inputs by double-clicking on them. This is the kind of behavior that you can encapsulate in a custom directive, let’s say InputClearDirective. Its selector will be an attribute, let’s say nsInputClear. When this attribute is added to an element, we want to listen for a double-click on this host element.

Let’s create the directive:

And use our directive like this:

We now need to react on a 'dblclick' event on our host element (here, the input) to clear the value.

That’s where we can use the HostListener decorator! This decorator can be added to a method of a directive, to indicate to the framework that this method needs to be called if the event given as parameter to the decorator is triggered on the host element.

In our case, we can write:

Now, every time a 'dblclick' event is triggered on the host element, the directive will clear the input value.

Note that it is also possible to listen to global events, like window:resize for example:

Also note that you can access the event in the method, by specifying ['$event'] as a second parameter of the decorator.

Another decorator available to create advanced directives and components is HostBinding. Whereas HostListener allows to interact with the events on the host element, HostBinding allows to interact with the properties of the host element.

Let’s say we want to add a specific CSS class (is-required) to an input if this input has a specific validation error (required). Maybe this class adds a nice border around the input, or a small asterisk, that’s not really important. This will not validate the field in any way, it will simply grab the result of the built-in Angular form validation, and use this result to style the input.

This is, again, a task that perfectly fits a directive:

We will use it in a code-driven Angular form:

or in a template driven one:

We then need to grab a reference to the status of the input in our directive. Angular does automatically validate the fields, and will add the required error if the field is required and not filled. That’s where the powerful dependency injection system can help us! You can indeed ask Angular to inject into a directive another directive applied to the same host, or to one of its ancestors.

As we want our directive to work with FormControlName or NgModel, we could ask Angular to inject these two. But it would break as only one of the two will be available (as you generally either use one or the other on a given input), and Angular breaks if a dependency can’t be provided. There is a trick that allows Angular to continue even if a dependency can’t be provided: the Optional decorator.

So something like this could work:

But that’s not the best we can do. Indeed, both directives inherits the same base class: NgControl. So instead of injecting one or the other, we can simply ask Angular to provide us the common NgControl!

Now that we have a reference to the NgControl, it’s easy to know if the field has the required error, by using its hasError() method. The last step requires us to add the class is-required to our host element if that’s the case. That’s where the HostBinding decorator enters the scene! This decorator allows to bind a property of the host element to a field of our directive. So it is generally used like this:

And that would automatically update the host’s value, every time the innerValue property of the directive would change.

In our case, we don’t have a field to bind to. But we can define a getter that returns true or false, depending on the field’s error, and decorate this getter with HostBinding to automatically add or remove the class is-required:

These few lines of code are really powerful: every time the directive is used in a form, Angular will automatically add or remove our custom class depending on the new value entered by the user!

It can be used to bind other kinds of properties, not just CSS classes. For example, some component libraries use it to add accessibility attributes (aria.xxx) to a host element.

Note that the directive we built has a custom selector, but if you decide that you want to apply these directives to every input, you can change their selector to input, and they will automatically be applied on every input of your application.

We already mentioned internationalization before, in the chapter about pipes. Three of the built-in Angular pipes deal with internationalization, and use the standard JavaScript Internationalization API, which is supposed to be provided by the browser. Those are the pipes number, currency and date.

What we don’t know yet is how these three pipes decide how to format the numbers and dates. Should they use a dot or a comma as decimal separator? Should they use January or Janvier for the first month of the year? You might think that this is decided based on the preferred language configured in the browser, but actually, it’s not. This depends on an injectable value named LOCALE_ID. And the default value of LOCALE_ID is 'en-US'.

Here is an example showing how to get the value of LOCALE_ID. As you can see, it’s a simple string value. To inject it into your components or services, you can’t just rely on its type. You need to tell Angular which token identifies the value, using @Inject(LOCALE_ID). This can be useful if your logic needs to know which locale the application is using.

This is good. But how can we change the locale? Actually, you can’t. The locale is a constant, that you can’t change once the application has started. But that doesn’t mean you can’t set it to another value before the application starts. This is possible, simply by providing another value for the LOCALE_ID token in your root Angular module.

Here’s an example showing how to do that, and its effect on our component:

If you want to create an application that uses only one locale, but different from 'en-US', then setting the locale as explained above is all you need to do. But often, this is not enough, and you want to really internationalize your application.

If you have used AngularJS 1.x before, and have internationalized your AngularJS application, you probably know that there is nothing built-in to display translated text based on the preferred language of the user.

One of the popular libraries to achieve that with AngularJS is angular-translate. The strategy it uses is fairly common: you use a directive or a pipe to translate a key (for example 'home.welcome'). This key identifies a message, and you provide the translations for all the languages you want to support (for example: 'Welcome' and 'Bienvenue'). At runtime, the directive or pipe uses the preferred language to get the appropriate translation, and updates the DOM with the translated message. You can change the preferred language at runtime, and all the messages on the page are immediately translated to the new language.

Internationalization is now provided by Angular directly (although it was hardly usable before version 4.0). No need for an external dependency anymore. And it uses basically the same strategy based on keys, but with a big difference: this happens at compile-time rather than happening at runtime. When the application starts, or, if you use the Angular AOT compiler, when you build your app, Angular parses all the HTML templates of your components, and transforms them to JavaScript code that, basically, analyses the changes in the model and modifies the DOM accordingly. This is when the translation happens. That has important consequences:

In the remaining parts of this chapter, we will assume that you use Angular CLI to build your application. The tools are actually available and usable outside of Angular CLI, because they’re part of the Angular ngc compiler. But since they’re well integrated and simple to use in Angular CLI, and since it’s the recommended way to build your applications anyway, we will use that.

We will also use the AOT compiler to build and serve internationalized versions of our application. This is indeed the simplest way to do that. If you want to test the internationalization in JIT mode (i.e. without precompiling the templates at build time), it requires a substantial modification of the code used to bootstrap the application. Please refer to the internationalization cookbook in the official documentation if you really want to do that.

That said, how do we proceed? You already know how to create components and write their templates. Will you have to rewrite everything to internationalize them? Thankfully, no. The process is the following one:

Let’s examine each of those steps in more details.

Sometimes, the text you need to translate is not in the templates, but is in the TypeScript code itself. For example, the three states of a pony race PENDING, RUNNING and FINISHED should be translated somehow. The current plan is to be able to do something like the following.

Unfortunately, this is not implemented yet. A temporary solution can be, for example, to load JSON translation files from the server based on the LOCALE_ID.

Sometimes, the message you want to display depends on the number of elements in a collection, or on a count of elements.

For example, let’s say our home page displayed the number of planned races for the day. You could simply show "Number of planned race(s): 4". But a friendlier message would be "No race is planned" if there is none, or "Only one race is planned" if there is just one, or "N races are planned" in the other cases.

Angular actually has a special template syntax to do that. It’s hard to read, except maybe for LISP programmers, but it does the job and is fairly easy to understand with the following example. Suppose our component has a property racesPlanned, containing the number of races that are planned for today. You can display it as:

To internationalize this message, you would just use the i18n attribute as usual:

Extracting this generates two translation units, one for the message itself, and one for the expression bundled in the message:

Unfortunately, the second translation unit has an auto-generated ID, and the pluralization syntax must be understood and respected by the translator. It’s possible to translate those two translation units, though, and the translation works as expected:

These best practices, acquired in years of development of i18ned applications, are not necessarily related to Angular, but to i18n in general.

Always specify an explicit unique ID for your messages. If you choose a meaningful ID, you often don’t need to specify a meaning and a description for your message, because the ID is sufficient. Prefixing the IDs with the name of the component where they are used (like I did in all the example with the home. prefix) allows knowing where they are used, and finding them in the code easily. Relying on auto-generated IDs doesn’t allow having different translations for two identical messages in your source language. It also makes it very hard to figure out what needs to be changed between two releases of your application.

Even if the translators are not always developers, store your messages files in your version control system. This makes sure a branch can have its own additions, that can be merged to the main branch when ready. It makes it easy to spot differences between branches and releases.

Duplication isn’t necessarily bad. You might think that two pages sharing a label "Save" or "OK" should use the same key, but maybe you will want to label them "OK, I’ll do it" and "OK, I accept" later. Or maybe they need to be differentiated in some foreign language. It’s even more important to use two separate keys for words that are identical in English, but not in other languages, like "free", which can mean "free as in beer" or "free as in speech". Other languages use different words for these two concepts.

Don’t confuse languages with countries. Don’t use country flags to represent languages. Some languages (like English) are spoken in several countries. And some countries use several languages (like Belgium, which uses French, Dutch and German).

Avoid concatenation to translate text with parameters. For example, to translate "Hello, my name is X and I’m Y years old", don’t use a first key for "Hello, my name is ", a second key for " and I’m " and a third key for " years old". Use a single key, containing interpolated expressions.

You should now be ready to conquer the world with your shiny i18ned Angular application.