9d2e715baab928f5bedb837bfcb70b2b

Guest Author

Gabor Soos

Learn how to test Components in Angular. We will start with writing isolated tests for a component and finish with integration tests for the rendered component.



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-664"></i>
  <strong>Get the "Migrating an Angular 1 App to Angular 2 book" for Free.</strong> Spread the word and <a href="https://auth0.com/e-books/migrating-to-angular2">download it now!</a>
</div>

Components enable us to display content on our website. The Angular compiler parses component templates and
displays them according to the given state. The business logic inside the components can be tested with
traditional unit tests just like services. But what happens with the displayed HTML
from the template and the interaction with other components? In this tutorial I'll show you
how to test the rendered components, starting from isolated unit tests to fully integrated ones.

This article is the third part of a series in which
I share my experiences testing different building blocks of an Angular application.
It relies heavily on Dependency Injection based testing and it is recommended that you read
[the first part](https://auth0.com/blog/angular-2-testing-in-depth-services/)
if you are not familiar with the concepts.

- [Services](https://auth0.com/blog/angular-2-testing-in-depth-services/)
- [HTTP Services](https://auth0.com/blog/angular-testing-in-depth-http-services/)
- Components (this article)
- Pipes
- Routing

### The component we'll test

The component we will test is a login form. It doesn't directly access the Authentication service,
instead it just informs the parent component about the submission through an `Output` property.
The form consists of two fields: an email and a password field.
The email address can be preloaded through an `Input` property
if it is passed down from the wrapping parent component.

<p align="center">
  <img src="https://images.ctfassets.net/23aumh6u8s0i/NefimDEZKVVWDa8hgzpEo/31fbf004d320b3262d4509cda24729a3/login-form" alt="Angular Testing Framework"/>
</p>

The two fields are handled by a reactive form created in the component.
With reactive forms, we can add validation to the fields and access their values without touching the DOM.
I've chosen reactive forms because they are more flexible and easier to test than template-driven forms.
Template-driven forms can only be tested through the DOM, making test writing harder.

If you are not familiar with reactive forms, it is recommended to read
[this part from the official documentation](https://angular.io/docs/ts/latest/guide/reactive-forms.html).

The [`FormBuilder`](https://angular.io/docs/ts/latest/api/forms/index/FormBuilder-class.html)
is created inside the constructor and adds validation to the input fields.
When the `email` input changes, the [`ngOnChanges`](https://angular.io/docs/ts/latest/api/core/index/OnChanges-class.html)
lifecycle hook passes it down to the field.
Setting the value on one of the forms control also updates its value in the HTML input element.

```typescript
import { Component, EventEmitter, Input, Output } from '@angular/core';
import { FormBuilder, FormGroup, Validators } from '@angular/forms';

@Component({
  selector: 'login-form',
  templateUrl: './login-form.template.html'
})
export class LoginFormComponent {

  private loginForm: FormGroup;

  constructor(private formBuilder: FormBuilder) {
    this.loginForm = this.formBuilder.group({
      email: ['', [Validators.required, Validators.email]],
      password: ['', Validators.required]
    });
  }

  @Input()
  email: string;

  @Output()
  submitted = new EventEmitter();

  ngOnChanges(change) {
    if (change.email) {
      this.loginForm.controls['email'].setValue(change.email.currentValue);
    }
  }

  onSubmit({ email, password }) {
    this.submitted.emit({ email, password });
  }
}
```

The template only includes tags that are necessary for the form to function.
The value of the `formControlName` property will be the reference name
when we access our inputs inside the form controls.
With the `[formGroup]` property, we fire up the form handling with the components `FormGroup` and
listen to form submissions with `(ngSubmit)`.
When we click on the submit button, Angular will catch the event and pass it to the `onSubmit` handler function.

```html
<form (ngSubmit)="onSubmit(loginForm.value)" [formGroup]="loginForm">
    <input type="text" formControlName="email" id="login-email">

    <input type="password" formControlName="password" id="login-password">

    <button type="submit">Log In</button>
</form>
```

### Isolated tests

If we just want to focus on the business logic, we can treat and test the component as a service.
The `Component` decorator extends the `Injectable` decorator, which means it can be created as a service.
We just have to pass the component to the `providers` array in the module dependencies.
When testing in isolation, the template never gets compiled.
It only gets the required dependencies through the constructor.

```typescript
import { LoginFormComponent } from './login-form.component';
import { FormsModule, ReactiveFormsModule } from '@angular/forms';
import { TestBed, inject, async } from '@angular/core/testing';
import { Component } from '@angular/core';

describe('Isolated', () => {
  let subject: LoginFormComponent;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [LoginFormComponent],
      imports: [FormsModule, ReactiveFormsModule]
    });
  });

  beforeEach(inject([LoginFormComponent], (loginForm: LoginFormComponent) => {
    subject = loginForm;
  }));

  it('should send credentials on submit', () => {
    subject.submitted.subscribe(({ email, password }) => {
      expect(email).toEqual(expectedEmail);
      expect(password).toEqual(expectedPassword);
    });

    subject.onSubmit({ email: expectedEmail, password: expectedPassword });
  });
});
```

The test focuses on the method that is called when the form is submitted.
It only passes the given email and password to the `EventEmitter` after destructuring the input object.
We don't have to pass Jasmine's asynchronous `done` callback to the testcase
because the `EventEmitter` acts synchronously.

Isolated tests are good when you want to focus on the component's logic.
These tests are also much faster than any other solution.
The only downsides are that it won't detect errors in the template
nor check the interactions with other components.

### Shallow tests

If we also want to detect errors inside the template, but still focus on a single component,
shallow tests are the way to go.
The key difference compared to isolated tests is that here the component is compiled.

Inside the `beforeEach` block, the component class moves to the `declarations` property instead of `providers`.
Before we can create an instance of the component, it has to be compiled.
The `compileComponents` method does the task asynchronously. It can't be synchronous,
because templates and styles can be referenced with relative urls
and the fetching of these resources is asynchronous by nature.
We have to wait for these tasks to complete. We can do the waiting with the `async` helper function.
In the background, `async` creates a new zone
and waits until every asynchronous operation is finished within that zone.
This way, we don't have to fiddle with Jasmine's `done` callback.

```typescript
describe('Shallow', () => {
  beforeEach(async(() => {
    TestBed.configureTestingModule({
      declarations: [LoginFormComponent],
      imports: [FormsModule, ReactiveFormsModule]
    });
    TestBed.compileComponents();
  }));

  it('should send credentials on submit', () => {
    let fixture = TestBed.createComponent(LoginFormComponent);
    let component: LoginFormComponent = fixture.componentInstance;
    let element = fixture.nativeElement;

    fixture.detectChanges();

    element.querySelector('#login-email').value = expectedEmail;
    element.querySelector('#login-email').dispatchEvent(new Event('input'));
    element.querySelector('#login-password').value = expectedPassword;
    element.querySelector('#login-password').dispatchEvent(new Event('input'));

    fixture.detectChanges();

    component.submitted.subscribe(({ email, password }) => {
      expect(email).toEqual(expectedEmail);
      expect(password).toEqual(expectedPassword);
    });

    element.querySelector('button[type="submit"]').click();
  });
});
```

With the `createComponent` method, we will have access to the component instance(`componentInstance`)
and the generated HTML fragment (`nativeElement`). We test the same thing as before:
what is emitted on the output at form submission.
The big difference is that we fill the inputs and click the submit button.
Filling the inputs with valid data is necessary
because the form validation leaves the submit button disabled as long as the inputs contain invalid data.

To make the component work, we have to call the `detectChanges` method after every change.
The `detectChanges` method does the synchronization of the component instance and the generated HTML.
Otherwise the component won't know that the input's value has changed.
When we modify an input, triggering the `input` event manually is also necessary
because this is the event that Angular listens for.

Also before doing anything inside the `nativeElement`, we have to call `detectChanges` first.
Calling the method does the first round of property checks on the component and fills out the template based on it.

Finally, we can use the native DOM methods and selectors on the `nativeElement` property.

With shallow tests, we gain the ability to test the templates, but it comes with a price.
These tests run much slower by including the compilation step.

### Integration tests

The next step is to test the component through its interactions with other components.
With integration tests, not only the template, but inputs and outputs will also be tested.

The setup is very similar to shallow tests. We have to set up and compile components.
The difference is that we have one more component that uses the login form component inside its template.
The wrapper component passes down the predefined email address and listens for the submit event.

```typescript
describe('Integration', () => {
  @Component({
    selector: 'site',
    template: `<login-form [email]="email" (submitted)="onFormSubmit($event)"></login-form>`
  })
  class SiteComponent {
    email = expectedEmail;

    storedEmail: string;

    storedPassword: string;

    onFormSubmit({ email, password }) {
      this.storedEmail = email;
      this.storedPassword = password;
    }
  }

  beforeEach(async(() => {
    TestBed.configureTestingModule({
      declarations: [LoginFormComponent, SiteComponent],
      imports: [FormsModule, ReactiveFormsModule]
    });
    TestBed.compileComponents();
  }));

  it('should send credentials on submit', () => {
    let fixture = TestBed.createComponent(SiteComponent);
    let component: SiteComponent = fixture.componentInstance;
    let element = fixture.nativeElement;

    fixture.detectChanges();

    expect(element.querySelector('#login-email').value).toEqual(expectedEmail);

    element.querySelector('#login-password').value = expectedPassword;
    element.querySelector('#login-password').dispatchEvent(new Event('input'));

    fixture.detectChanges();

    element.querySelector('button[type="submit"]').click();

    expect(component.storedEmail).toEqual(expectedEmail);
    expect(component.storedPassword).toEqual(expectedPassword);
  });
});
```

The modification of the input fields is the same, but the assertions are different.
This time we don't write assertions for the login form, but write them for the wrapper component instead.
This way, we ensure the bindings are correct.

There is no considerable slowdown compared to shallow tests. Integration tests need a bit more setup upfront,
but we can test the interactions between the components.

<include src="asides/Angular" />

### Summary

We have learnt three methods to test Angular components.
The first and fastest is testing the component in isolation:
we don't compile the template, just focus on the callable methods, like with a service.
If we also want to test the template, we will have to compile that component.
These are shallow tests. They are slower, but test more parts.
The last missing aspect is the interaction with other components. This can be tested with integration tests.
The extra element here is that we need to write a wrapper component around the component under test
and observe it through the wrapping component.

Either type we choose, we have to find the right balance between speed and how deeply we test the components.
It is optimal if we test business through isolation tests
and add some shallow and integration tests to ensure interactions and the template are valid.

To see the tests in action, check out
[this GitHub repository](https://github.com/blacksonic/angular2-testing-ground "Angular testing ground").


Angular Testing In Depth: Components

Learn how to test HTTP services in Angular. We will start by writing tests for requests and finish by refactoring them to a cleaner format.



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-664"></i>
  <strong>Get the "Migrating an Angular 1 App to Angular 2 book" for Free.</strong> Spread the word and <a href="https://auth0.com/e-books/migrating-to-angular2">download it now!</a>
</div>

When we write a web application, most of the time it has a backend.
The most straightforward way to communicate with the backend is with HTTP requests.
These requests are crucial for the application, so we need to test them.
More importantly, these tests need to be isolated from the outside world.
In this article I will show you how to test your requests properly and elegantly.

This article is the second part of a series in which
I share my experiences testing different building blocks of an Angular application.
It relies heavily on Dependency Injection based testing and
it is recommended that you read [the first part](https://auth0.com/blog/angular-2-testing-in-depth-services/)
if you are not familiar with the concepts.

- [Services](https://auth0.com/blog/angular-2-testing-in-depth-services/)
- HTTP Services (this article)
- [Components](https://auth0.com/blog/angular-testing-in-depth-components/)
- Pipes
- Routing

### Testing our first request

<p align="center">
  <img src="https://github.com/blacksonic/articles/raw/master/img/angular2-testing-http-services/github-logo.png" alt="Angular Testing Framework"/>
</p>

To get started we will test a basic request, the GET request.
It will call a parameterized url without a body or additional headers.
The [Github API](https://developer.github.com/v3/) has an endpoint for retrieving public profile information about users.
The profile information is returned in JSON format.

```typescript
import { Injectable } from '@angular/core';
import { Http, Response } from '@angular/http';
import 'rxjs/add/operator/map';

@Injectable()
export class GithubService {
  constructor(private http: Http) {}

  getProfile(userName: string) {
    return this.http
      .get(`https://api.github.com/users/${userName}`)
      .map((response: Response) => response.json());
  }
}
```

The ```getProfile``` method sends a GET request to the API and returns the response.
Every request made with the ```HttpModule``` returns an ```Observable.```
The returned value will always be a ```Response``` object, which can return the response body.
With the help of the ```json``` or ```text``` method we can transform the value of the Observable.

The first thing we have to do is to set up the test dependencies.
The ```Http``` dependency is required.
If we don't provide it, we will get this error message: ```No provider for Http!```.

```typescript
beforeEach(() => {
  TestBed.configureTestingModule({
    providers: [GithubService],
    imports: [HttpModule]
  });
});
```

The problem with the real ```HttpModule``` is that we will end up sending real HTTP requests.
It is an absolutely terrible idea to do this with unit tests, because it breaks the test's isolation from the outside world.
Under no circumstances will the result of the test be guaranteed.
For example, the network can go down and our well-crafted tests will no longer work.

Instead, Angular has a built-in way to fake HTTP requests.

```typescript
import { MockBackend, MockConnection } from '@angular/http/testing';
import { Http, BaseRequestOptions, Response, ResponseOptions, RequestMethod } from '@angular/http';

...

beforeEach(() => {
  TestBed.configureTestingModule({
    providers: [
      GithubService,
      MockBackend,
      BaseRequestOptions,
      {
        provide: Http,
        useFactory: (mockBackend: MockBackend, defaultOptions: RequestOptions) => {
          return new Http(mockBackend, defaultOptions);
        },
        deps: [MockBackend, BaseRequestOptions]
      }
    ]
  });
});
```

Instead of providing ```Http``` as a module,
it is better to use the factory provider and pass the ```MockBackend``` instance to the ```Http``` constructor.
This way the fake backend captures every request and can respond accordingly.

Before writing the first test it is also important to get an instance of the ```MockBackend,```
because without it we won't be able to respond to requests.

```typescript
beforeEach(inject([GithubService, MockBackend], (github, mockBackend) => {
  subject = github;
  backend = mockBackend;
}));
```

Let's write the first test that checks the result of the request.

```typescript
it('should get profile data of user', (done) => {
  let profileInfo = { login: 'sonic', id: 325, name: 'Tester' };
  backend.connections.subscribe((connection: MockConnection) => {
    let options = new ResponseOptions({ body: profileInfo });

    connection.mockRespond(new Response(options));
  });

  subject.getProfile('blacksonic').subscribe((response) => {
    expect(response).toEqual(profileInfo);
    done();
  });
});
```

Requests made are available through the ```connections``` property of the fake backend as an ```Observable.```
When it receives the request through the ```subscribe``` method we can respond with a JSON object.

In our example only the response body is set. In addition, you can set the status and the headers of the request.

Another new element is the ```done``` callback that is passed into the test function.
It is needed when writing asynchronous tests.
This way the test doesn't end when the execution of the function ends.
It will wait until the ```done``` callback is called.
Of course, there is a timeout for hanging tests that don't call this ```done``` method within a given interval.

HTTP requests are asynchronous by nature,
but the fake backend we use responds to them synchronously (it calls the ```subscribe``` method synchronously).
You may wonder what makes the test asynchronous, then.

The answer is false positive tests.
If we comment out the response to the request, the test will still pass, even though we have an assertion.
The problem here is that the ```subscribe``` callback never gets executed if we don't respond to the request.

```typescript
it('should get profile data of user', () => {
  // backend.connections.subscribe...

  subject.getProfile('blacksonic').subscribe((response) => {
    expect(response).toEqual(profileInfo);
  });
});
```
### Checking the request

Until now we haven't made any assertions for the request.
For example, what was the called url, or what was the method of the request?
To make the test more strict we have to check these parameters.

```typescript
backend.connections.subscribe((connection: MockConnection) => {
  expect(connection.request.url).toEqual('https://api.github.com/users/blacksonic');
  expect(connection.request.method).toEqual(RequestMethod.Get);

  ...
});
```

The original ```Request``` object resides on the ```MockConnection``` object.
With its ```url``` and ```method``` property, we can add the assertions easily.

### Digging deeper

GET requests are good for retrieving data, but we'll make use of other HTTP verbs to send data.
One example is POST.
User authentication is a perfect fit for POST requests.
When modifying data stored on the server we need to restrict access to it.
This is usually done with a POST request on the login page.

<p align="center">
  <img src="https://github.com/blacksonic/articles/raw/master/img/angular2-testing-http-services/auth0-logo.png" alt="Angular Testing Framework"/>
</p>

Auth0 provides a good solution for handling user authentication.
It has a feature to authenticate users based on username and password.
To demonstrate how to test POST requests, we will send a request to the Auth0 API.
We won't be using their recommended package here, because it would abstract out the actual request,
but for real-world scenarios I would recommend using it.

```typescript
@Injectable()
export class Auth0Service {
  constructor(private http: Http) {}

  login(username: string, password: string) {
    let headers = new Headers({
      'Content-Type': 'application/json'
    });
    let options = new RequestOptions({ headers });

    return this.http
      .post(
        'https://blacksonic.eu.auth0.com.auth0.com/usernamepassword/login',
        { username, password, client_id: 'YOUR_CLIENT_ID' },
        options
      )
      .map((response: Response) => response.text());
  }
}
```

The main difference between this example and the previous one is that here we are sending a JSON payload to the server
and appending additional headers onto it.
We don't have to manually ```JSON.stringify``` the payload --- the request methods will take care of it.
The response will be in text format, so this time we don't have to convert anything to JSON.

Let's look at the test to see how we can check every detail of the request.

```typescript
it('should be called with proper arguments', (done) => {
  backend.connections.subscribe((connection: MockConnection) => {
    expect(connection.request.url).toEqual('https://blacksonic.eu.auth0.com.auth0.com/usernamepassword/login');
    expect(connection.request.method).toEqual(RequestMethod.Post);
    expect(connection.request.headers.get('Content-Type')).toEqual('application/json');
    expect(connection.request.getBody()).toEqual(JSON.stringify(
      {
        username: 'blacksonic',
        password: 'secret',
        client_id: 'YOUR_CLIENT_ID'
      }, null, 2
    ));
    ...
  });

  subject.login('blacksonic', 'secret').subscribe((response) => {
    expect(response).toEqual('<form />');
    done();
  });
});
```

The headers are also available on the ```Request``` object and can be checked one by one.
The payload can be retrieved with the ```getBody``` method.
This method always returns the body converted to a string, which will we see in the network traffic.
When we send JSON it will contain the output of the ```JSON.stringify``` method: printed with spaces and an indentation of two.

### Refactoring

The previous setup works, but it has multiple problems.

- For every service we test, the provider configuration will be exactly the same.
- The subscription to the outgoing connection responds the same immediately, regardless of the url.
- The assertions are verbose and hard to read.

Those who have tested their HTTP services in Angularjs may remember how simple the setup was for those tests.
Angularjs provided convenient methods for setting expectations on requests.

Angular doesn't have those built-in functionalities,
but very similar ones are present in the [ngx-http-test](https://github.com/blacksonic/ngx-http-test) library.

It can solve the problems mentioned earlier.
Let's look at the test with the library for the Github profile fetch.

```typescript
...
import { FakeBackend } from 'ngx-http-test';

describe('GithubServiceRefactored', () => {
  ...

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [
        GithubService,
        FakeBackend.getProviders()
      ]
    });
  });

  beforeEach(inject([GithubService, FakeBackend], (github, fakeBackend) => {
    subject = github;
    backend = fakeBackend;
  }));

  it('should get profile data of user', (done) => {
    backend
      .expectGet('https://api.github.com/users/blacksonic')
      .respond(profileInfo);

    subject.getProfile('blacksonic').subscribe((response) => {
      expect(response).toEqual(profileInfo);
      done();
    });
  });
});

```

The setup becomes a function call to ```FakeBackend.getProviders()```.
Setting the expectation hides the subscription and gives more readable methods like ```expectGET```.

The login test also becomes less verbose.

```typescript
it('should be called with proper arguments', (done) => {
  backend.expectPost(
    'https://blacksonic.eu.auth0.com.auth0.com/usernamepassword/login',
    {
      username: 'blacksonic',
      password: 'secret',
      client_id: 'YOUR_CLIENT_ID'
    },
    { 'Content-Type': 'application/json' }
  ).respond(responseForm);

  subject.login('blacksonic', 'secret').subscribe((response) => {
    expect(response).toEqual('</form>');
    done();
  });
});
```

## Aside: Securing Angular Applications with Auth0

Are you building a product with Angular? We at Auth0, can help you focus on what matters the most to you, the special features of your product. [Auth0](https://auth0.com/) can help you make your product secure with state-of-the-art features like [passwordless](https://auth0.com/passwordless), [breached password surveillance](https://auth0.com/breached-passwords), and [multifactor authentication](https://auth0.com/multifactor-authentication). [We offer a generous **free tier**](https://auth0.com/pricing) to get started with modern authentication.

We provide the simplest and easiest to use [User interface tools to help administrators manage user identities](https://auth0.com/user-management) including password resets, creating and provisioning, blocking and deleting users.

### Conclusion: What we've learned about Angular HTTP testing

In this tutorial, we managed to:

- setup tests and fake an HTTP backend
- write assertions for requests
- refactor the tests to be more readable

Angular has the tools to test HTTP requests, but still lacks the readable assertion methods that were present in Angularjs.
Until such methods are implemented, the [ngx-http-test](https://github.com/blacksonic/ngx-http-test) library can be used.

To see the tests in action check out
[this GitHub repository](https://github.com/blacksonic/angular-testing-ground "Angular testing ground").


Angular Testing In Depth: HTTP Services

bruno-krebs

I am passionate about developing highly scalable, resilient applications. I love everything from the database, to microservices (Kubernetes, Docker, etc), to the frontend. I find amazing to think about how all pieces work together to provide a fast and pleasurable experience to end users, mainly because they have no clue how complex that "simple" app is.

R&D Content Architect

Bruno Krebs

Single Page Applications (SPAs) can benefit greatly from JWT secured backends. Here we will see how to secure an Angular 2 app, backed by Koa, with JWTs.

Building and Securing Koa and Angular 2 with JWT

eHk3ciM

I am the Group Manager, Developer Content at Okta, and a Google Developer Expert in Web Technologies and Angular. I'm passionate about identity, authentication, constant learning, and developer communities. As a developer advocate, engineer, mentor, and international speaker, I love learning from and sharing with other inhabitants of the tech space.

Group Manager, Developer Content

Kim Maida

Learn how to migrate real-world features of an AngularJS 1 application to a fresh Angular 2+ build (Part 3): routing  & API with params, authentication.

Migrating an AngularJS App to Angular - Part 3

Learn how to migrate real-world features of an AngularJS 1 application to a fresh Angular 2+ build (Part 2): routing, API, and filtering.

Migrating an AngularJS App to Angular - Part 2

Learn how to migrate real-world features of an AngularJS 1 application to a fresh Angular 2+ build (Part 1): setup, architecture, and components.

Migrating an AngularJS App to Angular - Part 1

Learn how to test services in Angular. We will start with setting up the environment and finish with using Dependency Injection.



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-664"></i>
  <strong>Get the "Migrating an Angular 1 App to Angular 2 book" for Free.</strong> Spread the word and <a href="https://auth0.com/e-books/migrating-to-angular2">download it now!</a>
</div>

When I started developing and writing tests for Angularjs applications,
everything felt natural. The tools were mature and I easily got used to
developing applications in TDD ([Test-Driven Development](https://en.wikipedia.org/wiki/Test-driven_development)).
It gave me a high level of confidence, knowing that my application was working as I had imagined.
Just after Angular 2 came out and I learned the basics, I knew that the next step was to testing.

This article is the first part of a series in which
I share my experiences testing different building blocks of an Angular application.
We will start with simple use cases and then head for more complex ones.

- Services (this article)
- [Http Services](https://auth0.com/blog/angular-testing-in-depth-http-services/)
- [Components](https://auth0.com/blog/angular-testing-in-depth-components/)
- Pipes
- Routing

You may wonder why it is so important to write tests.

<p align="center">
  <img src="https://github.com/blacksonic/articles/raw/master/img/angular2-testing-services/tdd_guilty.png" alt="Angular Testing Driven Development"/>
</p>

With tests, we can ensure the correctness of our application: that the code does what it was designed to do.
We can guard against someone breaking our code by refactoring or
adding new features. This might have happened to you when someone added a small feature
or equivalent code transformations and nothing worked afterwards.
Writing tests can clarify the intention of the code by giving usage examples.
It can also reveal design flaws. When a piece of code is hard to test,
there might be a problem with the underlying architecture.

If you are new to Test-Driven Development, I would recommend reading the Test-Driven Development book by Kent Beck.
It gives a nice overview about the concepts and best practices.

### Choosing the framework to test Angular

<p align="center">
  <img src="https://github.com/blacksonic/articles/raw/master/img/angular2-testing-services/jasmine-mocha.png" alt="Angular Testing Framework"/>
</p>

The first thing we have to choose is the framework. The one suggested by Angular's core team is
[Jasmine](http://jasmine.github.io/edge/introduction.html).
For a long time it was the only supported testing framework, because test setups were hard wired into the framework.
Thanks to refactoring, now tests can also be written in [Mocha](https://mochajs.org/), or any other framework
that supports the ```beforeEach``` hook. This hook runs before every test run.
If your framework of choice doesn't support it, you have to add the following code snippet to your setup:

```typescript
import { resetFakeAsyncZone, TestBed } from '@angular/core/testing';

beforeEveryTestHook(() => {
  TestBed.resetTestingModule();
  resetFakeAsyncZone();
});
```

The first line within the hook resets the internal state of the Dependency Injection container.
It clears out any given provider or module.
If you are not familiar with Dependency Injection, I would recommend reading the
[official documentation](https://angular.io/docs/ts/latest/guide/dependency-injection.html) about it.

The second one clears out any remaining zone that fakes asynchronous operations like ```setTimeout```.
Detailed articles can be found on the Thoughtram blog about zones:
[Understanding zones](http://blog.thoughtram.io/angular/2016/01/22/understanding-zones.html) and
[Zones in Angular](http://blog.thoughtram.io/angular/2016/02/01/zones-in-angular-2.html).

For this series, we will be using Jasmine as the test framework.

### Writing the first Angular test

Let's look at our first service that will be tested.

```typescript
import { Injectable } from '@angular/core';

@Injectable()
export class Engine {
  getHorsepower() {
    return 150;
  }

  getName() {
    return 'Basic engine';
  }
}
```

It has two getter methods and the ```Injectable``` decorator.
The tests will check whether these getter methods work as intended.
The decorator is needed to utilize dependency injection.

In Jasmine, we can group our tests with the ```describe``` method.
Within this method, we can create test cases with the ```it``` function.
It is advised to place one class per file (the service) and group the tests around it (with ```describe```).
We can further group test cases around methods of the class
by placing ```describe``` statements inside the top ```describe``` block.
For now we will only group our tests around the class.

```typescript
import { Engine } from './engine.service';

describe('Engine', () => {
  it('should return it\'s horsepower', () => {
    let subject = new Engine();

    expect(subject.getHorsepower()).toEqual(150);
  });
});
```

In this setup, only plain instantiation is used; we will introduce dependency injection later.
For basic services, plain instantiation can be enough.

We call the ```getHorsepower``` method of the engine and check that it's equal to the expected value.

The first test is green and has been passed. Let's write another one for the ```getName``` method.

```typescript
it('should return it\'s horsepower', () => {
  let subject = new Engine();

  expect(subject.getName()).toEqual('Basic engine');
});
```

If you run the tests, a similar output will be on the terminal.

![Angular First Tests](https://github.com/blacksonic/articles/raw/master/img/angular2-testing-services/first_test_run.png)

Both tests have been passed; it is time to refactor.
There is duplication at the start of each Angular test. Instantiation is exactly the same,
we can move it out into a setup block.

```typescript
describe('Engine', () => {
  let subject: Engine;

  beforeEach(() => {
    subject = new Engine();
  });

  it('should return it\'s horsepower', () => {
    expect(subject.getHorsepower()).toEqual(150);
  });

  it('should return it\'s horsepower', () => {
    expect(subject.getName()).toEqual('Basic engine');
  });
});
```

The ```subject``` variable is declared at the start of the ```describe``` block, and the creation of the service
is moved to the ```beforeEach``` block. This way we don't have to do it manually every time.
It is common to move the creation of the test case subject to a separate method,
because it offloads the tests and makes them more readable.

### Using Dependency Injection

Creating services directly can be good if the subject under test has no or few, dependencies.
But if it has multiple dependencies, or a deeper dependency tree, setting up all the classes becomes tedious.
For these situations, we can use Angular's dependency injection management.

The ```Car``` class uses the ```Engine``` class in the constructor and its instance in the ```getName``` method.

```typescript
import { Injectable } from '@angular/core';
import { Engine } from './engine.service';

@Injectable()
export class Car {
  constructor(private engine: Engine) {}

  getName() {
    return `Car with ${this.engine.getName()}(${this.engine.getHorsepower()} HP)`;
  }
}
```

We check for the ```getName``` method's output in the test after we set up the dependency injection container.

```typescript
import { TestBed, inject } from '@angular/core/testing';
import { Engine } from './engine.service';
import { Car } from './car.service';

describe('Car', () => {
  let subject: Car;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [Engine, Car]
    });
  });

  beforeEach(inject([Car], (car: Car) => {
    subject = car;
  }));

  it('should display name with engine', () => {
    expect(subject.getName()).toEqual('Car with Basic engine(150 HP)');
  });
});
```

The difference here is that we configure the ```TestBed``` with the provided
services in the ```configureTestingModule``` method.
Only these classes can be instantiated with the ```inject``` method.
If we try to request something else, we get an error saying it is an unknown provider.

![Angular Testing Error](https://github.com/blacksonic/articles/raw/master/img/angular2-testing-services/test_failure_missing_dep.png)

We can request instances of the services in an array from the ```inject``` method.
In the callback, we get the instances in the same order as in the dependency array with the first parameter.
The type hint inside the  callback is only for IDE completion; it also works without it.
In the example, it is placed inside the ```beforeEach``` function, but it can also be added to the ```it``` block.

```typescript
it('should display name with engine', inject([Car], (car: Car) => {
  expect(car.getName()).toEqual('Car with Basic engine(150 HP)');
}));
```

### Mocking

In unit tests for Angular, we want to execute the code in isolation.
This means it is not dependent on big, complex objects and is not calling methods that rely on external systems
(like [HTTP calls](https://auth0.com/blog/angular-2-series-part-3-using-http/) or database access).
In these cases, we want to simulate the original behavior while skipping the underlying implementation.

When achieved, it is called mocking.
We don't have to do it manually. Jasmine provides tools to make it work.
Let's assume that the method of the ```Engine``` class has a call through to the server
and we want to mock it.

```typescript
...
beforeEach(() => {
  TestBed.configureTestingModule({
    providers: [Engine, Car]
  });

  spyOn(Engine.prototype, 'getHorsepower').and.returnValue(400);
  spyOn(Engine.prototype, 'getName').and.returnValue('V8 engine');
});

...

it('should display name with engine', () => {
  expect(subject.getName()).toEqual('Car with V8 engine(400 HP)');
});
```

We mock the class methods by calling the ```spyOn``` method on the class's prototype.
We also alter the return value of the function. This way the original method never gets called.
When mocking the prototype, it affects every instance of the class.

### Using Dependency Injection for Mocking

The previous solution for mocking can be achieved also with Angular's dependency injection mechanism.
We pass the ```Engine``` class as the provider token, but create the instances with a fake class.

```typescript
@Injectable()
class V8Engine {
  getHorsepower() {
    return 400;
  }

  getName() {
    return 'V8 engine';
  }
}
```

Then we pass this fake class to the setup.

```typescript
beforeEach(() => {
  TestBed.configureTestingModule({
    providers: [
      { provide: Engine, useClass: V8Engine },
      Car
    ]
  });
});
```

With this setup, the ```inject``` call will return an instance of ```V8Engine``` when asked for ```Engine```.
We can also use ```useFactory``` with a callback, or ```useValue``` with an instance, to accomplish the same result.
The only drawback here is that every method of the class must be implemented and changed
whenever the original class changes.
The original class can be extended optionally in order to override only specific methods.

<include src="asides/Angular" />

## Conclusion: What we've learned about Angular Testing

In this tutorial, we managed to:

- create a basic service and write tests for it
- use dependency injection in tests
- fake dependencies with Jasmine
- fake dependencies with dependency injection

If you follow the steps introduced in this article and write tests for your Angular application, you can sleep safe and sound.
The code will work as intended and when someone accidentally breaks it,
the tests will warn him that those changes are unsafe and shouldn't be committed until the tests are green again.

Jasmine will help you along the way with its easy syntax and batteries included (assertion and mocking library).

I hope this has convinced you that writing tests in Angular is not an overly complicated thing.

To make the start even easier, the code is available in
[this GitHub repository](https://github.com/blacksonic/angular-testing-ground "Angular testing ground").


Angular Testing In Depth: Services

df6c864847fba9687d962cb80b482764?size=200 avatar

df6c864847fba9687d962cb80b482764?size=200

Martin Gontovnikas, a.k.a Gonto, is a software engineer at heart who moved to the ‘dark side’ and became VP of Marketing at Auth0. He considers himself lucky to have found a way to combine his two passions and apply his engineering thinking model to marketing.<br/><br/> Gonto’s analytical thinking is a huge driver of his data-driven approach to marketing strategy and experimental design. He is based in the Bay area, and in his spare time, can be found eating gourmet food at the best new restaurants, visiting every local brewery he can find, or traveling the globe in search of new experiences.

Former SVP of Marketing and Growth at Auth0

Martin Gontovnikas

Learn how to create a real world angular 2 app using Pipes, Directives, Components, DI, ES6 and much more! We'll implement from Authentication to calling an API and everything in between

Build your Angular 2 App: From Auth to calling an API

a28d70be6ae2b9389db9ad815cab510e

Wojciech Kwiatek

Angular 2 introduces a new change detection system that makes apps much faster and allows developers fine-tune the process.



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-664"></i>
  <strong>Get the "Migrating an Angular 1 App to Angular 2" book for free.</strong> Spread the word and <a href="https://auth0.com/e-books/migrating-to-angular2">download it now!</a>
</div>

---

**TL;DR** Angular 2 introduces a reinvented change detection system that drops digest cycles in favor of one-way flow. Additionally, change detection can now be controlled and fine-tuned by developers to get the most of the framework's performance.

---

## Introduction to Change Detection
Angular 2 final has been released. You've probably heard about some of the changes due to the major version bump: it's has been completely rewritten, TypeScript was selected as the language of choice, reinvented forms, RxJS, a completely new router, etc. In my opinion, the most valuable thing is the redesign of the core change detection system. As you may remember, the digest loop performance of AngularJS (aka Angular 1) was problematic. Now it's not.

### Why Do We Need Change Detection?
Why bother? Generally, the power of modern JavaScript frameworks works something like this: an event changes in the model and forcing a change in the UI. This is change detection, the system that monitors events and acts on them. Something has to trigger this propagation to the view. As mentioned before, in Angular 1 we had digest loops that checked every single reference that was set to be watched for value changes. When Angular found out that everything was stable (no infinite loops, etc.), it propagated changes to the view. Although this was not efficient, it worked for a long time. Also, the problem was tracking asynchronous events. You also probably used `$scope.$apply(...)` if you worked with Angular 1. To understand why it was needed, let's start from the beginning.

### How Javascript works
The JavaScript runtime works on a single threaded engine. You've probably heard about the stack (possibly from other programming languages). Let's take the code below:

```js
console.log('Hey')
setTimeout(() => {
   console.log('Hello from timeout!')
}, 1000);
console.log('Hi')
```

We'll see this in a console as:

```html
Hey
Hi
Hello from timeout!
```

Moreover, nothing is blocked during the one-second wait period. So how would the JS engine do this with a single thread?

#### Synchronous code
Let's go step by step. If you have code like this:

```js
console.log('1')
console.log('2')
console.log('3')
```

every instruction will be put onto the stack and will run one by one. There's no possibility of seeing 3 before 2 or 1. So we'll end up with the following:

```
1
2
3
```

Every time. Everywhere.

#### Asynchronous code
But let's go back to the timeout:

```js
console.log('1')
setTimeout(() => {
  console.log('2')
}, 0)
console.log('3')
```

What happens now? On the stack, we'll have:

```js
console.log
setTimeout
console.log
```

The trick here is how `setTimeout` works and what it really is. Yes, it will be invoked as a normal synchronous action, but all the JS engine does is give the wheel to something else. There's a bunch of browser APIs that aren't part of this single threaded process. And there's a thing called event loop. This event loop goes one by one through the stack instructions, and if it's empty, it then goes to the *callback queue*. The reference to the `setTimeout` code is there. Once callback is done, the code will go to the stack.

What does it mean? Two things:

- Everything that's inside an asynchronous callback (as in `setTimeout`) will be run *after* any other synchronous code; this is why hacks like `setTimeout(() => {}, 0)` work.
- We have no way of ensuring 1000ms is *exactly* 1000ms (but we know it's at least 1000ms).

For complete understanding of event loop and what's going on in the browser, I encourage you to take a look at this [Philip Roberts talk](https://www.youtube.com/watch?v=8aGhZQkoFbQ).

### How Zones Relate to Change Detection
How does all of this relate to Angular and change detection? Tracking objects with synchronous code is fairly easy. However, when it comes to asynchronous code, things get complicated. That's because Angular 1 forced us to use `$scope.$apply(...)` each time an asynchronous action was made or use the Angular way of doing asynchronous actions: `$timeout`, `$http`, and so on. The thing is, if something was made outside of the controller (even a perfectly valid change to the reference object), Angular didn't know about it, so it didn't fire any event to reflect changes to the UI.

On the other hand, we now have Angular 2. It dropped all of the stuff connected to digest cycles and now uses *Zones*. Zones are able to track the context of asynchronous actions by monkey-patching them (i.e., overwriting them with its own code), which then invokes the desired action but with some additional information attached. This additional information is the context. This way, Angular will know which component the asynchronous action was invoked from.

The big win of this approach is that we can use the browser APIs natively, and Angular will know what's going on without forcing us to manually tell it a change has occured. The drawback is that Zones overwrite asynchronous actions, which is kind of a hacky solution and may affect other (existing) code if we're not relying only on Angular in the app.

But exactly how is Angular notified of the change? Angular uses its own version of the Zone called `NgZone`, which relays finished asynchronous actions with the `onTurnDone` event. Angular change detection waits for the event to perform change detection and checks what needs to be updated in the UI. That's the core behavior.

## Make Use of Change Detection In Your App
Everything described above is going on under the hood. Equally important is how we can make use of it. Unlike Angular 1, Angular 2 gives us the possibility of controlling the change detection. However, the Angular team claims that even without any performance tweaking, it's 3 to 10 times faster than the previous one, and for most apps this will be fast enough. But it can be much faster. Let's look at an example.

<iframe src="https://embed.plnkr.co/HR7ssEuPaWwlVKJPzZtJ/" width="100%" height="800"></iframe>

Here's a very typical problem: rendering a list. There's one component containing a list of other components that have some input data. Generally, we have a container with data and a dumb component just for rendering a single list item. Nothing fancy here, just the getter and `ngOnChange`. What's being done here? `ngOnChange` reacts on every input change, and the getter adds additional logging each time `rowData` are fetched. Note that we're not using it anywhere outside of the template.

This means the getter is fired by Angular itself. And guess what happens? We have a single change on the input, but there are hundreds of getter logs over there.

Why is that?

Angular is notified about the change from some component and has to check how that affects the current state, so it checks all the values for the change. Actually, the team says it can make thousands of such checks in milliseconds, but it's still a waste of time and can even harm our big data-driven application.

### Immutability
The cool thing about the new change detection system is that now we can tune it. Let's take a break from Angular and consider following code:

```js
const users = [{
  name: 'John',
  age: 27
}, {
  name: 'Anna',
  age: 23
}]

users.push({
  name: 'Max',
  age: 30
})
```

The most important thing here is the `const` declaration. If `users` is constant, how can we modify it? Well, that's how JavaScript works! The `const` prevents us from modifying a reference to the particular object in JavaScript. What the `push` method of `Array` is really doing is appending another object to the existing array (with no reference change). Let's go on to another very typical example:

```js
const user = {
  name: 'Max',
  age: 30
}

user.age = 31
```

The same thing applies. Although we can't modify the whole object to make it be another one (reference change), we still can change part of the object!

This is why the checks we discussed before aren't so good. If you want to check whether the object is the same as it was before, you have to *deeply check all of its properties*. It's not efficient.

How can we force the object to be a new one with the changed property? It's actually quite easy with the new [ECMAScript Object spread properties proposal](https://github.com/sebmarkbage/ecmascript-rest-spread):

```js
const user = {
  name: 'Max',
  age: 30
}

const modifiedUser = { ...user, age: 31 }
```

### Change Detection Strategies
The good part about all this is that now we can say to Angular that *we know what we're doing*. To modify the change detection behavior, we can use the `ChangeDetectionStrategy` API, which has one very interesting value: `OnPush`. It makes a component with this strategy applied look at the values inside only when the reference on the input changes or some event has been fired from the component.

Let's add the `OnPush` strategy to our previous example:

```ts
import {ChangeDetectionStrategy, Component, Input} from '@angular/core';

@Component({
  selector: 'row',
  template: `
    <pre>{{ rowData }}</pre>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class RowComponent {
  ...
}
```

You can try it on Plunker and see the difference.

<iframe src="https://embed.plnkr.co/d9b07qginx7z9hGYyeME/" width="100%" height="800"></iframe>

 The huge improvement is that there's now only one getter call for one change! We didn't need anything more as our input data are strings that are being changed, so that reference on input changes. The reference for the rest of the components hasn't changed, so Angular doesn't even look at it.

### App Structure
How can we build a highly performing app? With Angular 2, it's actually quite easy. As in all of the component frameworks nowadays, you should have dumb and smart components. The dumb components, which are meant only for displaying data from the input or handling user events, are ideal volunteers for having the `OnPush` strategy. Smart components will sometimes require that you watch for more things than the input and the events, so be careful with setting the `OnPush` strategy there.

<include src="asides/Angular" />

## Conclusions

### Performance Advantages
One of the big advantages of using stricter change detection is the performance gains. Angular is meant to be used for large applications that can handle lots of dynamic data. The Angular team has given the developer the tools necessary to fine-tune and improve performance from the get-go. By default, every change should be reflected on the UI, as Angular takes care of that, but the price is lower performance. Immutable or reactive code is harder to write but easier to maintain and reason out. The choice is yours.

### Eventually Angular can be tweaked
The good thing is that we have a choice with Angular 2. In Angular 1, it was impossible to get away from the digest cycle. At a certain point, it was advantageous to use React or another library to render UI instead of Angular templates, as it was too slow when handling a large amount of dynamic data. Now, you have a complete solution with much more control over the internal behavior. This, in combination with the other changes made to Angular 2, makes the learning curve of the framework steeper but worth it.


Understanding Angular 2 change detection

The Angular 2 @NgModule decorator allows for easier management of dependencies within the Angular 2 framework.

<div class="alert alert-danger alert-icon">
  <i class="icon-budicon-664"></i>
  <strong>This post is out of date.</strong> The Angular framework has undergone many changes since the publication of this post and the method of authentication utilized in this post is not up-to-date with current best practices. Please read <strong><a href="https://auth0.com/blog/real-world-angular-series-part-8/#ngmodules" target="_blank">Real-World Angular Series Part 8 - Refactor NgModules</a></strong> to learn about managing NgModules in modern Angular!
</div>

---

**TL;DR** Angular 2 RC 5 introduced a series of new features including [@NgModule](https://angular.io/docs/ts/latest/guide/ngmodule.html), lazy loading support for the router, and [Ahead-of-Time (AoT)](http://blog.mgechev.com/2016/08/14/ahead-of-time-compilation-angular-offline-precompilation/) compilation. In this post, we'll look at the new `@NgModule` decorator and see how it can make managing dependencies a lot easier. 

---

[Angular 2](https://angular.io/) has officially reached a major milestone, the [final 2.0 release](http://angularjs.blogspot.com/2016/09/angular2-final.html). The Release Candidate (RC) 5 version of the framework, released just a few weeks ago, introduced many new features that will make developing Angular 2 applications easier but also run better and faster. Among the new features is lazy loading support for the official router, Ahead-of-Time (AoT) compilation for components and services, a new and improved forms module, and a new decorator called @NgModule. 

**NgModule** aims to simplify the way you define and manage dependencies in your Angular 2 applications. Using `@NgModule` you can consolidate different components and services into cohesive blocks of functionality.  

<include src="TweetQuote" quoteText="@NgModule simplifies the way you define and manage dependencies in your Angular 2 apps."/>

## Angular 2 Without @NgModule

NgModule is a late, but greatly welcomed addition to the Angular 2 framework. Before diving into working with `@NgModule`, let's briefly look at life without it. If you've worked with Angular 2 applications before RC5, your components probably looked a little like this:

```js
@Component({
  selector: 'my-component',
  styles: [`
  h1 {
    font-size: 200px
  }
  `]
  template: `
  <h1>Hello from MyComponent.</h1>
  <my-other-component></my-other-component>
  `,
  providers: [MyProvider], // MyProvider is a fictional service
  directives: [MyOtherComponent] // MyOtherDirective is a fictional component
})
export class MyComponent {}
```

For each and every component you created, you had to declare the relationship it had with the various other components, services, and pipes within your application. It was very easy to forget to include the right component and it made managing all these dependencies very cumbersome. In addition to that, the error reporting was subpar, so you wouldn't even know why your components aren't loading or functionality seems broken.

## Enter @NgModule

`@NgModule` for the most part solves the problem of managing dependencies for your Angular 2 application. With `@NgModule`, you can group a certain feature, business logic, utility, or other logical unit of functionality into a module that contains all of the dependencies, components and services for that module. Then you are free to focus on building out your components, services, pipes, and directives without having to re-declare any of the dependencies again.

Let's see how this works in practice. We'll start by writing our root module. RC5 and future versions of Angular 2 will be bootstrapped with a module rather than a component, so our application must have a root module. We'll create our root module below.

```
import { NgModule }      from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';

import { AppComponent }  from './app.component';

@NgModule({
  imports: [ BrowserModule ],
  declarations: [ AppComponent ],
  bootstrap:    [ AppComponent ]
})
export class AppModule { }
```

Our `app.component.ts` file will be fairly simple:

```
import { Component } from '@angular/core';

@Component({
  selector: 'my-app',
  template: '<h1>NgModule Demo Application</h1>',
})
export class AppComponent {}
```

So far our syntax doesn't look drastically different from the pre-RC5 way of declaring our Angular 2 application. Sure the syntax has slightly changed, but is that really worth rewriting all of our code?

Next, let's add a component to our application. We'll call this component `WelcomeComponent` and it will simply display a welcome message. The implementation will be as follows:

```
import { Component } from '@angular/core';

@Component({
  selector: 'app-welcome',
  template: '<p>Welcome to our awesome app</p>',
})
export class WelcomeComponent {}
```

Now say we want to use this component in our `AppComponent`. Prior to RC5, we would:

1. Go into our `app.component.ts` file and import the `WelcomeComponent`
2. In the @Component decorator we'd add a directives key and pass the `WelcomeComponent` to it
3. Finally we'd add the `<app-welcome></app-welcome>` directive in our template.

This process would have to be repeated anywhere we wanted to use the `WelcomeComponent`. In a small application, it may be a slight annoyance, but as your application grows, it would quickly become tedious and unmanageable. 

Since we are writing an application that makes use of `@NgModule` we can omit steps one and two, and simply add the appropriate component in our template. Then, in our root `@NgModule`, we'd simply add the `WelcomeComponent` as a dependency.

```
// ...
@NgModule({
  imports: [ BrowserModule ],
  declarations: [ AppComponent, WelcomeComponent ],
  bootstrap:    [ AppComponent ]
})
export class AppModule { }
// ...
```

Since we declared this component in our root module, we can now use this `WelcomeComponent` anywhere in our application without needing to declare or import it again. In essence, the `@NgModule` handles dependency injection for us, so any component we declare will have the inherent knowledge of our other dependencies. We are not limited to declaring only components here, we could additionally write a directive or service, and declare use it the exact same way.

Let's talk a bit about the `imports` key. The `imports` key in the context of an `@NgModule` defines additional modules that will be imported into the current module. For example, we imported the `BrowserModule`, which adds a lot of common functionality like such as `ngIf` and `ngFor`. By importing the `BrowserModule` we get access to all of these directives without having to manually declare them ourselves. This really cuts down on having to redeclare and reimport a lot of common functionality. 

This was a minimalistic example showing how we can leverage the `@NgModule` decorator to simplify how we manage dependencies in our Angular 2 application. This was barely scratching the surface though. Check out the official [docs](https://angular.io/docs/ts/latest/guide/ngmodule.html) to learn all the ins and outs of `@NgModule`. In the next section, we'll look at how we can leverage the new NgModule features and add authentication to our Angular 2 app. 

## Aside: Angular 2 Authentication

We've shown how you can add JSON Web Token (JWT) authentication to your Angular 2 applications in the past. Many of these posts were written pre-RC5, so today I'll briefly discuss how you can combine our [Angular 2 JWT](https://github.com/auth0/angular2-jwt) library with `@NgModule` to write better, easier to understand, and more performant code. 

You may be familiar with the official Angular 2 demo application [Tour of Heroes](https://angular.io/docs/ts/latest/tutorial/). We have forked this app and created [Tour of Secret Heroes](https://github.com/auth0-blog/angular2-tour-of-heroes). In addition to familiarizing you with how Angular 2 works, our version also supports JSON Web Token based authentication. Let's take a look at how we accomplished this.

**Important security note:** In this demo, we're adding authentication to the client side but we are not securing a backend. If you have an API for your application, the API should _always_ be secured. The [`id_token` should not be used to secure an API](https://auth0.com/blog/why-should-use-accesstokens-to-secure-an-api); instead use an `access_token` with the appropriate configuration. You can read about how to [implement API authentication with Auth0](https://auth0.com/docs/apis) with [implicit grant](https://auth0.com/docs/api-auth/tutorials/implicit-grant).

First and foremost, we used the Angular 2 JWT library, created by Auth0. To install it in your application simply run `npm install angular2-jwt --save`.

Next, we created an authentication service in a file called `auth.service.ts`. The implementation is as follows:

```
import { Injectable } from '@angular/core';
import { tokenNotExpired } from 'angular2-jwt';
import { Router } from '@angular/router';

declare var Auth0Lock: any;

@Injectable()
export class AuthService {
  // Get the AUTH0_CLIENT_ID and AUTH0_DOMAIN from your management dashboard.
  lock = new Auth0Lock('AUTH0_CLIENT_ID', 'AUTH0_DOMAIN');

  constructor(private router: Router) {
    this.lock.on('authenticated', (authResult: any) => {
      localStorage.setItem('id_token', authResult.idToken);

      this.lock.getProfile(authResult.idToken, (error: any, profile: any) => {
        if (error) {
          console.log(error);
        }

        localStorage.setItem('profile', JSON.stringify(profile));
      });

      this.lock.hide();
    });
  }

  login() {
    this.lock.show();
  }

  logout() {
    // To log out, just remove the token and profile
    // from local storage
    localStorage.removeItem('profile');
    localStorage.removeItem('id_token');

    // Send the user back to the dashboard after logout
    this.router.navigateByUrl('/dashboard');
  }

  loggedIn() {
    return tokenNotExpired();
  }
}
```

The implementation uses the [Auth0 Lock](https://auth0.com/lock) widget. The Lock widget is a modern, easy to use, and very configurable login widget that can handle almost any authentication use case. To add the Lock widget to your application, in your `index.html` page add the following code:

```html
 
  
  <script src="//cdn.auth0.com/js/lock/10.2.2/lock.min.js"></script>

```

Next, we implemented an auth guard, which determines if the route should load or not. Our implementation is below:

```
import { Injectable } from '@angular/core';
import { Router } from '@angular/router';
import { CanActivate } from '@angular/router';
import { AuthService } from './auth.service';

@Injectable()
export class AuthGuard implements CanActivate {

  constructor(private auth: AuthService, private router: Router) {}

  canActivate() {
    if (!this.auth.loggedIn()) {
      this.router.navigate(['']);
      return false;
    }
    return true;
  }

}
```

The `AuthGuard` checks to see if a user is authenticated. For routes protected with the `AuthGuard`, the user must be logged in, otherwise the route does not load and they are redirected to the homepage. We've added a couple of routes to the Tour of Heroes that have this guard in place.


```
import { Routes, RouterModule, CanActivate } from '@angular/router';
import { AuthGuard } from './auth-guard.service';

import { DashboardComponent } from './dashboard.component';
import { HeroesComponent } from './heroes.component';
import { HeroDetailComponent } from './hero-detail.component';

import { SecretHeroesComponent } from './secret-heroes.component';
import { SecretHeroDetailComponent } from './secret-hero-detail.component';

const appRoutes: Routes = [
  {
    path: '',
    redirectTo: '/dashboard',
    pathMatch: 'full'
  },
  {
    path: 'dashboard',
    component: DashboardComponent
  },
  {
    path: 'detail/:id',
    component: HeroDetailComponent
  },
  {
    path: 'heroes',
    component: HeroesComponent
  },
  {
    path: 'secret-heroes',
    component: SecretHeroesComponent,
    canActivate: [AuthGuard]
  },
  {
    path: 'secret-detail/:id',
    component: SecretHeroDetailComponent,
    canActivate: [AuthGuard]
  },
];

export const routing = RouterModule.forRoot(appRoutes);

export const routedComponents = [DashboardComponent, HeroesComponent, HeroDetailComponent, SecretHeroesComponent, SecretHeroDetailComponent];
```

The additional routes have the `AuthGuard` activate meaning we'll check if the user is logged in only on these routes. For this application, we only created one `NgModule` and that was the root module. Let's take a look at it's implementation.

```
import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { FormsModule } from '@angular/forms';
import { HttpModule } from '@angular/http';
import { AUTH_PROVIDERS } from 'angular2-jwt';

import './rxjs-extensions';
import { AppComponent } from './app.component';
import { routing, routedComponents } from './app.routing';
import { HeroService } from './hero.service';
import { HeroSearchComponent } from './hero-search.component';

import { AuthService } from './auth.service';
import { AuthGuard } from './auth-guard.service';

@NgModule({
  imports: [
    BrowserModule,
    FormsModule,
    routing,
    HttpModule
  ],
  declarations: [
    AppComponent,
    HeroSearchComponent,
    routedComponents
  ],
  providers: [
    HeroService,
    AUTH_PROVIDERS,
    AuthService,
    AuthGuard
  ],
  bootstrap: [AppComponent]
})
export class AppModule { }
```

As you can see, we added a couple of different `imports`, `declarations`, and `providers`. Since this is our root module, we've also added a `bootstrap` key and passed in the correct component we want loaded first. One item to note is that we did not include all of our components here. The `DashboardComponent`, `HeroDetailComponent`, and others are not present here. Does this mean our app will not work? Not quite. Notice the `routedComponents` we added to our `declarations`. If we look in the `app.routing.ts` file, you'll notice that we grouped all of the components that we use in our routes in this array, and then exported it. This is totally valid and will work, while making our code a bit easier to read and understand.

The last change we made was in the `app.component.ts` file. Here we updated the template and added our `AuthService` so that we could conditionally display menu options based on the user state. Check out the implementation below:

```
import { Component } from '@angular/core';
import { AuthService } from './auth.service';

@Component({
  moduleId: module.id,
  selector: 'my-app',
  template: `
    <h1>{{title}}</h1>
    <nav>
      <a routerLink="/dashboard" routerLinkActive="active">Dashboard</a>
      <a routerLink="/heroes" routerLinkActive="active">Heroes</a>
      <a routerLink="/secret-heroes" *ngIf="authService.loggedIn()" routerLinkActive="active">Secret Heroes</a>
      <a (click)=authService.login() *ngIf="!authService.loggedIn()">Log In</a>
      <a (click)=authService.logout() *ngIf="authService.loggedIn()">Log Out</a>
    </nav>
    <router-outlet></router-outlet>
  `,
  styleUrls: ['app.component.css']
})
export class AppComponent {

  title = 'Tour of Heroes';

  constructor(private authService: AuthService) {}
}
```

That is it. We did create a `secret-heroes.component.ts` and `secret-hero-details.component.ts` components, but their functionality is equivalent to that of the regular `heroes.component.ts` and `hero-details.component.ts` components. Download the full Tour of Secret Heroes app from our [GitHub repo](https://github.com/auth0-blog/angular2-tour-of-heroes).

Stay tuned. We will be releasing a follow up post early next week that will walk you through building the Tour of Secret Heroes app from scratch and will go into further detail on how to add authentication to your Angular 2.0 apps.

## Conclusion

NgModule is a great and welcome addition to the Angular 2 framework. Managing dependencies in an application is never an easy task, but the `@NgModule` decorator is a great leap towards getting it right. If you aren't already using it in your Angular 2 applications, updating to RC5 and beyond is well worth it for this functionality alone. If you are building Angular 2 applications and are looking to do authentication right, check out our [Angular 2 JWT library](https://github.com/auth0/angular2-jwt) and <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up</a> for a free Auth0 account to get up and running in no time.

Use @NgModule to Manage Dependencies in your Angular 2 Apps

ryan-chenkie

Ryan is a full-stack JavaScript developer and trainer who mainly works with React, Angular, Node, and GraphQL. He runs a consultancy where he builds apps for companies and also helps established dev teams with their modern JavaScript challenges.<br /><br />Ryan is a Google Developer Expert, the host of the Entrepreneurial Coder Podcast, the author of Securing Angular Applications, and an all-around fanatic about application security.

Developer

Ryan Chenkie

Learn all about the new Angular 2 router and how to set it up in your app.

Angular 2 Series - Part 4: Component Router In-Depth

Build a simple image calculator app with Angular 2 and Electron

<div class="alert alert-danger alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>This post is out of date.</strong> Angular and Electron have undergone many changes since the publication of this article, and the method of authentication utilized in this post is not up-to-date with current best practices. We are currently working to bring you an updated tutorial on this topic!
</div>

---
**TL;DR:** Electron is an open-source project from GitHub that lets us create cross-platform desktop applications with web technologies. It doesn't matter which specific framework we use; if it works for the web, it works for Electron. We can use Angular 2 for Electron apps, and in this tutorial, we explore how to get a desktop image size calculator app wired up. Check out the [code on GitHub](https://github.com/auth0/angular2-electron).

You can also check out our other Angular 2 material, including tutorials on working with **[pipes](https://auth0.com/blog/2015/09/03/angular2-series-working-with-pipes/)**, **[models](https://auth0.com/blog/2015/09/17/angular-2-series-part-2-domain-models-and-dependency-injection/)**, and **[Http](https://auth0.com/blog/2015/10/15/angular-2-series-part-3-using-http/)**.

---

Developing desktop applications is arguably harder than developing for the web. Throw in the fact that you would need three versions of the same desktop app to make it available for all the popular operating systems, plus all the work that needs to go into preparing for distribution, and it can be a daunting task for web developers to port their skills to native. This is where Electron comes in.

[Electron](http://electron.atom.io/) is an open-source project from GitHub that makes it easy to build cross-platform desktop apps using web technologies. With it, we get a nice set of APIs for interacting with Windows, OS X, and Linux operating systems, and all we need is JavaScript. There are, of course, other ways to create desktop applications with web technologies, but Electron is unique in its ability to easily target three operating systems at once. The other nice part of building apps with Electron is that we're not barred from using any particular framework. As long as it works on the web, it works for Electron.

In this article, we'll explore how to wire up a simple image size calculator app using Electron and Angular 2. While the steps here are specific to Angular 2, remember that any front end framework will work with Electron, so these instructions could be adapted to make use of others.

![image-size-calculator app angular2 electron](https://images.ctfassets.net/23aumh6u8s0i/2fBM1k5s9xBpjOreXjDQOI/448998a3ffed9dcb695e41f15324ab25/angular2-electron-5)

## Setting Up Angular 2 and Electron

We'll use [Webpack](https://webpack.github.io/) for our Angular 2 setup, and we'll base the config loosely on the awesome [Angular 2 Webpack Starter](https://github.com/AngularClass/angular2-webpack-starter) by [AngularClass](https://angularclass.com/).

Let's start with our `package.json` file to list our dependencies, along with some `scripts` that will let us easily run our `webpack` commands and also run the `electron` command to start the app.

```js
// package.json
...

  "scripts": {
    "build": "webpack --progress --profile --colors --display-error-details --display-cached",
    "watch": "webpack --watch --progress --profile --colors --display-error-details --display-cached",
    "electron": "electron app"
  },
  "devDependencies": {
    "electron-prebuilt": "^0.35.4",
    "es6-shim": "^0.34.0",
    "ts-loader": "^0.7.2",
    "typescript": "^1.7.3",
    "webpack": "^1.12.9",
    "webpack-dev-server": "^1.14.0"
  },
  "dependencies": {
    "angular2": "2.0.0-beta.0",
    "zone.js": "^0.5.10",
    "bootstrap": "^3.3.6",
    "gulp": "^3.9.0",
    "es6-shim": "^0.33.3",
    "reflect-metadata": "0.1.2",
    "rxjs": "5.0.0-beta.0"
  }
}

...
```

Next, we need some configuration for Webpack.

```js
// webpack.config.js

var path = require('path');
var webpack = require('webpack');
var CommonsChunkPlugin = webpack.optimize.CommonsChunkPlugin;

module.exports = {
  devtool: 'source-map',
  debug: true,

  entry: {
    'angular2': [
      'rxjs',
      'reflect-metadata',
      'angular2/core',
      'angular2/router',
      'angular2/http'
    ],
    'app': './app/app'
  },

  output: {
    path: __dirname + '/build/',
    publicPath: 'build/',
    filename: '[name].js',
    sourceMapFilename: '[name].js.map',
    chunkFilename: '[id].chunk.js'
  },

  resolve: {
    extensions: ['','.ts','.js','.json', '.css', '.html']
  },

  module: {
    loaders: [
      {
        test: /\.ts$/,
        loader: 'ts',
        exclude: [ /node_modules/ ]
      }
    ]
  },

  plugins: [
    new CommonsChunkPlugin({ name: 'angular2', filename: 'angular2.js', minChunks: Infinity }),
    new CommonsChunkPlugin({ name: 'common',   filename: 'common.js' })
  ]
};
```

We're telling Webpack to bundle up the Angular 2 scripts and serve them from a single `angular2.js` bundle that will be in the `build` directory. The scripts for our app will be served from a separate bundle called `app.js`.

We also need some TypeScript configuration in a `tsconfig.json` file at the project root.

```js
{
  "compilerOptions": {
    "target": "ES5",
    "module": "commonjs",
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "sourceMap": true
  },
  "files": [
    "app/app.ts"
  ]
}
```

All the files specific to our application will live inside the `app` subdirectory. There, we need to provide a `package.json` file that will simply tell Electron which script to use for bootstrapping. This will be the `main.js` file, and in it, we will tell Electron how to open and close our app.

```js
// app/package.json

...

{
  "name": "image-size-calculator-app",
  "version": "0.0.1",
  "main": "main.js"
}

...
```

Now let's configure the application window.

```js
// app/main.js

var app = require('app');

// browser-window creates a native window
var BrowserWindow = require('browser-window');
var mainWindow = null;

app.on('window-all-closed', function () {
  if (process.platform != 'darwin') {
    app.quit();
  }
});

app.on('ready', function () {

  // Initialize the window to our specified dimensions
  mainWindow = new BrowserWindow({ width: 1200, height: 900 });

  // Tell Electron where to load the entry point from
  mainWindow.loadURL('file://' + __dirname + '/index.html');

  // Clear out the main window when the app is closed
  mainWindow.on('closed', function () {

    mainWindow = null;

  });

});
```

The `main.js` script is really just some boilerplate that Electron needs to fire up. We are keeping a reference to `mainWindow` so that garbage collection doesn't interfere and close the window on us. We create a browser window with specific dimensions and then load an `index.html` file from the `app` directory. Let's create this file next.

Just like with a regular web app, we need an `index.html` entry point.

```html
  

  <html>
    <head>
      <meta charset="UTF-8">
      <title>Image Size Calculator</title>
      <link rel="stylesheet" href="../node_modules/bootstrap/dist/css/bootstrap.min.css">
    </head>
    <body>

      <div class="container">
        <h1>Hello Electron</h1>
      </div>

      <script src="../node_modules/angular2/bundles/angular2-polyfills.js"></script>
      <script src="../build/common.js"></script>
      <script src="../build/angular2.js"></script>
      <script src="../build/app.js"></script>
    </body>
  </html>
```

Aside from `angular2-polyfills.js`, The scripts that we're referencing aren't actually there yet, and that's because we haven't run our `webpack` command to generate them. The last thing we need to do before bundling our scripts is to create an empty `app.ts` file, as this is what our `webpack.config.js` file expects.

With an empty `app.ts` in place, let's bundle the scripts.

```bash
npm run watch
```

This command was set up in our `package.json` file in the project root, and it runs `webpack` with some options. One of these options is to watch for changes, so we can now edit our `app.ts` file and everything will automatically get bundled again.

If we look in our project root, we should now see our `build` directory. With all these files in place, we should be able to run the app. Remember that we've set up a command in our `package.json` file to do this.

```bash
npm run electron
```

If everything is wired up properly, we should now see our "Hello Electron" message.

![image-size-calculator app angular2 electron](https://images.ctfassets.net/23aumh6u8s0i/3KaDOlbF2X37s1KJ0b3dJu/fded35bbeaeff006121565f3de209d61/angular2-electron-1)

Yikes, that was a lot of boilerplate needed just to set things up! It's worth noting that a lot of this was just to set up Angular 2 and wasn't because of Electron specifically. If we were using a simpler framework (e.g., no TypeScript) or just plain JavaScript, then we wouldn't have needed as much boilerplate. The good news is that all we need to worry about now is the actual Angular 2 code. It's time to start building the app just as we would if it were on the web!

## Creating the Image Uploader

Our simple app will let users drop images in so that they can find out their sizes. Why wouldn't they just check the image's properties? Good point. However, this app will give us a chance to see how Electron adapts web APIs for the desktop.

Let's create the dropzone first. We'll do all of our Angular 2 work in one top-level component.

```js
// app/app.ts

import {bootstrap} from 'angular2/platform/browser';
import {Component} from 'angular2/core';
import {NgFor} from 'angular2/common';

@Component({
  selector: 'app',
  template: `
    <div
      (dragover)="false"
      (dragend)="false"
      (drop)="handleDrop($event)"
      style="height: 300px; border: 5px dotted #ccc;">
      <p style="margin: 10px; text-align: center">
        <strong>Drop Your Images Here</strong>
      </p>
    </div>
  `
})

export class App {

  constructor() {}

  handleDrop(e) {
    var files:File = e.dataTransfer.files;
    Object.keys(files).forEach((key) => {
      console.log(files[key]);
    });

    return false;
  }

}

bootstrap(App);
```

```html
  

  ...

  <div class="container">
    <app></app>
  </div>

  ...
```

To define some custom behavior for dropping an image into our app, we need to first pass `false` to the `dragover` and `dragend` events. The `drop` event is what we want to hook into, and for now we are simply logging out the details of the images we drop. That's right--we can see the same dev tools that we would in Chrome. If you're on a Mac, just do `Option + Command + I` to open them up.

Note that to get hold of the event information for the drop, we pass `$event`, just like we would in Angular 1.x.

![image-size-calculator app angular2 electron](https://images.ctfassets.net/23aumh6u8s0i/7nt2TZsoTBz2ZqQa6jZvYi/bc67dffc61a0d6496b158793cc4e3bd0/angular2-electron-2)

So how are we getting this information, exactly? Electron provides an abstraction around native files so that we can use the HTML5 file API. With this, we get the path to the file on the filesystem. This is useful in our case, because we can link to our images and show them in our app. Let's set that up now.

## Displaying the Images

Let's now put in some templating to display the images. For this, we'll want to use `ngFor` to iterate over the images we drop in.

> **Note:** As of Beta, templates are now case-sensitive. This means that what used to be `ng-for` is now `ngFor`.

```js
// app/app.ts

...

  template: `
    <div class="media" *ngFor="#image of images">
      <div class="media-left">
        <a href="#">
          <img class="media-object" src="{{ "{{ image.path " }}}}" style="max-width:200px"/>
        </a>
      </div>
      <div class="media-body">
        <h4 class="media-heading">{{ "{{ image.name " }}}}</h4>
        <p>{{ "{{ image.size " }}}} bytes</p>
      </div>
    </div>
`

...

export class App {

  images:Array<Object> = [];

  constructor() {}

  handleDrop(e) {
    var files:File = e.dataTransfer.files;
    var self = this;
    Object.keys(files).forEach((key) => {
      if(files[key].type === "image/png" || files[key].type === "image/jpeg") {
        self.images.push(files[key]);
      }
      else {
        alert("File must be a PNG or JPEG!");
      }
    });

    return false;
  }

}

...
```

Now we push the dropped files onto an array called `images` and iterate over it in our template to get the details. To avoid other file types being dropped in, we are only accepting `png` and `jpeg`.

![image-size-calculator app angular2 electron](https://images.ctfassets.net/23aumh6u8s0i/75fUdePu8wSB9bM6BhTKV1/3ca9251b245cdb7f2576c942c17d5590/angular2-electron-3)

## Getting the Image Stats

We want to have a way to display the total number of images dropped into the app, as well as the total size of those images. For this, we can create an `imageStats` function that returns these details.

```js
// app/app.ts

...

  template: `
    <h1>Total Images: {{ "{{ imageStats().count " }}}}</h1>
    <h1>Total Size: {{ "{{ imageStats().size " }}}} bytes</h1>
  `
...

  imageStats() {

    let sizes:Array<Number> = [];
    let totalSize:number = 0;

    this
      .images
      .forEach((image:File) => sizes.push(image.size));

    sizes
      .forEach((size:number) => totalSize += size);

    return {
      size: totalSize,
      count: this.images.length
    }

  }

...
```

![image-size-calculator app angular2 electron](https://images.ctfassets.net/23aumh6u8s0i/65q7cneMZuaXcNthZwWOQ8/3a9df1aa3f362386abf251a7bb29c751/angular2-electron-4)

## Adding a Byte Conversion Pipe

We're getting the number of bytes for each image, but ideally we would be able to get them in different units. It would be great if we had something to automatically convert the bytes to KB, MB, and GB, and display the appropriate units. We can do this easily with a custom pipe.

```js
// app/app.ts

import {bootstrap} from 'angular2/platform/browser';
import {Component, Pipe, PipeTransform} from 'angular2/core';
import {NgFor} from 'angular2/common';

@Pipe({ name: 'byteFormat'})
class ByteFormatPipe implements PipeTransform {
  // Credit: http://stackoverflow.com/a/18650828
  transform(bytes, args) {
    if(bytes == 0) return '0 Bytes';
    var k = 1000;
    var sizes = ['Bytes', 'KB', 'MB', 'GB'];
    var i = Math.floor(Math.log(bytes) / Math.log(k));
    return (bytes / Math.pow(k, i)).toFixed(1) + ' ' + sizes[i];
  }
}

@Component({
  selector: 'app',
  pipes: [ByteFormatPipe],
  template: `
    <h1>Total Images: {{ "{{ imageStats().count " }}}}</h1>
    <h1>Total Size: {{ "{{ imageStats().size | byteFormat " }}}}</h1>
  `
...
```

This pipe checks for the file size in bytes and returns the appropriate conversion. We then just apply the pipe to our template and we're able to get the desired output.

![image-size-calculator app angular2 electron](https://images.ctfassets.net/23aumh6u8s0i/2fBM1k5s9xBpjOreXjDQOI/448998a3ffed9dcb695e41f15324ab25/angular2-electron-5)

## Preparing for Distribution

When distributing Electron apps, it's essential to generate an archive of the application files so that the source code is concealed. This can be done with the `asar` utility.

<include src="TweetQuote" quoteText="When distributing Electron apps, generate an archive of the application files so that the source is concealed."/>

```bash
npm install -g asar
asar pack image-size-calculator app.asar
```

The archive file can then be used for the app, and it will be read-only.

We'll obviously want to change the name of the application and also provide a unique icon. Instructions for this, along with the other steps involved with distribution, can be found in the [Electron docs](http://electron.atom.io/docs/v0.35.0/tutorial/application-packaging/).

## Aside: Authentication with Auth0

No matter which framework you use with your Electron app, you can easily add authentication to it with Auth0! Our Lock widget allows you to get up and running quickly. Sign up for your <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">free Auth0 account</a> to work with these directions.

Before getting started with the code, you'll need to whitelist the `file://*` protocol in your Auth0 dashboard. This can be done in the **Allowed Origins (CORS)** area.

To begin, include the **Auth0-Lock** library from the CDN and provide a button or other element to hook into.

```html
  

  ...

  
  <script src="https://cdn.auth0.com/js/lock-7.12.min.js"></script>

  
  <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />

  <body>
    <h1>Authenticate with Auth0!</h1>
    <button id="login">Login</button>

  ...
```

Next, create a new instance of Lock and set `window.electron` to an empty object to trigger the proper login flow for Electron.

```html
  

  <script>

    var lock = new Auth0Lock('YOUR_CLIENT_ID', 'YOUR_CLIENT_DOMAIN');

    window.electron = {};

  </script>
```

Finally, trigger the Lock widget to be shown when the user clicks the **Login** button. In the callback, set the returned user profile and token into local storage for use later.

```html
  

  <script>

    ...

    document.getElementById('login').addEventListener('click', function() {
      lock.show(function(err, profile, token) {
        if (err) {

          // Error callback
          console.error("Something went wrong: ", err);

        } else {

          // Success calback. Save the profile and JWT token.
          localStorage.setItem('profile', JSON.stringify(profile));
          localStorage.setItem('id_token', token);

        }
      });
    });

  </script>
```

> **Important API Security Note:** If you want to use Auth0 authentication to authorize _API requests_, note that you'll need to use [a flow that provides an access token](https://auth0.com/docs/api-auth/grant/implicit). Auth0 [`idToken` should only be used on the client-side, whereas access tokens should be used to authorize APIs](https://auth0.com/blog/why-should-use-accesstokens-to-secure-an-api/). You can read more about [making API calls with Auth0 here](https://auth0.com/docs/apis).
> 
> The way to attach the header to HTTP calls differs depending on which library or framework you're using. If you're using Angular v2+ in your Electron app, you can use **[angular2-jwt](https://www.npmjs.com/package/angular2-jwt)**. Follow the steps in the [Angular docs](https://auth0.com/docs/quickstart/spa/angular2/no-api) for more details. Not using Angular v2+? We have got [integrations](https://auth0.com/docs) for many other frameworks and libraries as well!

## Wrapping Up

Electron offers developers a way to create desktop applications with the web technologies they already know instead of needing to learn new languages that are specific to various operating systems. This is great, because skills can easily be ported, and code can be reused.

Electron doesn't care about which framework we use for our apps. Even though it's in beta, Angular 2 is a great framework to use inside an Electron app and, once everything is set up, works just the same as if we were developing for the web.

Create a Desktop App with Angular 2 and Electron

Learn the differences between $http in Angular 1.x and Http in Angular 2. Find out how to use the RxJS Observables that Http returns.



---
**TL;DR:** Making **HTTP requests in Angular 2 apps** looks somewhat different than what we're used to from Angular 1.x, a key difference being that Angular 2's **Http** returns **observables**. In this tutorial, we cover how to use Http to make requests and how to handle the responses. We'll also see how we can do basic authentication for an Angular 2 app. Check out [the repo](https://github.com/auth0/angular2-http) for the tutorial to see the code.

This is Part 3 in our Angular 2 series. Be sure to check out [Part 1 on Pipes](https://auth0.com/blog/2015/09/03/angular2-series-working-with-pipes/) and [Part 2 on Models](https://auth0.com/blog/2015/09/17/angular-2-series-part-2-domain-models-and-dependency-injection/).

---

It's fair to say that most of Angular 2 looks and feels completely different than Angular 1.x, and the **Http** API is no exception. The **$http** service that Angular 1.x provides works very nicely for most use cases, and is fairly intuitive to use. Angular 2's Http requires that we learn some new concepts, including how to work with **observables**.

In this tutorial, we'll look at some of the key differences in the way that Angular 1.x and 2 implement **HTTP requests**, and we'll also see how to make requests and handle responses. Incidentally, the sample we use to test out **Http** will also let us see the basics of adding authentication to an Angular 2 app.

It's important to note that the Http implementation for Angular 2 is still a [work in progress](https://github.com/angular/angular/issues/2793), and a lot of things are still in flux or aren't complete yet.

## Differences between Angular 1.x $http and Angular 2 Http

**Angular 2's Http implementation** again provides a fairly straightforward way of handling requests, but there are some key differences. For starters, **HTTP calls in Angular 2** by default return observables through [RxJS](https://github.com/Reactive-Extensions/RxJS), whereas $http in Angular 1.x returns promises. Using observable streams gives us the benefit of greater flexibility when it comes to handling the responses coming from HTTP requests. For example, we have the potential of tapping into useful RxJS operators like `retry` so that a failed HTTP request is automatically re-sent, which is useful for cases where users have poor or intermittent network communication. We'll see later in the article how we can implement RxJS operators in our Http observables.

In Angular 2, Http is accessed as an injectable class from `angular2/http` and, just like other classes, we `import` it when we want to use it in our components. Angular 2 also comes with a set of injectable providers for Http, which are imported via `HTTP_PROVIDERS`. With these we get providers such as `RequestOptions` and `ResponseOptions`, which allow us to modify requests and responses by extending the base class for each. In Angular 1.x, we would do this by providing a `transformRequest` or `transformResponse` function to our `$http` options.

In Angular 1.x we can transform requests globally in the application's `config`.

```js
.config(function($httpProvider) {
  $httpProvider.defaults.transformRequest = function(data) {
    return JSON.stringify({name: "Ryan"});
  }
});
```

Whereas in Angular 2, we would extend the `BaseRequestOptions`.

```js
class MyOptions extends BaseRequestOptions {
  body: string = JSON.stringify({name: "Ryan"});
}

bootstrap(App, [HTTP_PROVIDERS, provide(RequestOptions, {useClass:MyOptions})]);
```

## Http in Action

Let's take a look at how we can perform some basic requests with Http. We'll see how to work with `POST` and `GET` requests by using our trusty [NodeJS Chuck Norris quote backend](https://github.com/auth0/nodejs-jwt-authentication-sample), which will require us to retrieve and store a JWT, and thereby implement basic authentication.

## Getting Started

As we have in our other Angular 2 articles, we'll use [Pawel Kozlowski's](https://twitter.com/pkozlowski_os) [ng2-play](https://github.com/pkozlowski-opensource/ng2-play/) repo for this tutorial. To get started, clone the repo and run `npm install`, then `gulp play`.

We also need to get our random quote server running. With the Angular 2 seed project installed, let's clone and install the quote server in the root of our project.

We also need to set up our `app` component by importing what we need and providing a template.

```js
// app.ts

import {Component, View} from 'angular2/angular2';
import {Http, Headers} from 'angular2/http';
import {CORE_DIRECTIVES, FORM_DIRECTIVES} from 'angular2/angular2';

@Component({
  selector: 'app'
})

@View({
  directives: [ CORE_DIRECTIVES, FORM_DIRECTIVES ],  
  template: `
  <header>
    <h1 class="title">Angular 2 HTTP</h1>
  </header>

  <section>
    <h2>Login</h2>
    <form #f="form" (ng-submit)="authenticate(f.value)">
      <div ng-control-group="credentials">
          <label for="username">Username</label>
          <input
            type="text"
            id="username"
            ng-control="username"
            required>

          <label for="password">Password</label>
          <input
            type="password"
            id="password"
            ng-control="password"
            required>
      </div>

      <button>Login!</button>

    </form>

  </section>

  <section>
    <h2>Random Quote</h2>
    <hr>
      <h3>{{ "{{randomQuote" }}}}</h3>
    <button (click)="getRandomQuote()">Get Random Quote!</button>
  <section>

  <section>
    <h2>Secret Quote</h2>
    <hr>
    <h3>{{ "{{secretQuote" }}}}</h3>
    <button (click)="getSecretQuote()">Get Secret Quote!</button>
  <section>
  `
})

export class App {

  constructor(public http: Http) {

  }

}

bootstrap(App, [HTTP_BINDINGS])
```

As you can see, we've imported some familiar pieces like `Component` and `View`, but we are also pulling in `Http` and `Headers`. We'll see it later on, but we can modify the headers we send in our requests with the `Headers` class.

We're making use of a form for the user to eventually provide their credentials. The form calls an `authenticate` method on submit.

In the `App` class, we're passing `Http` to the constructor so that we can use it in our class methods.

## Simple GET Request

Let's start with a simple `GET` request to the `api/random-quote` route which doesn't require authentication.

```js
getRandomQuote() {
  this.http.get('http://localhost:3001/api/random-quote')
    .map(res => res.text())
    .subscribe(
      data => this.randomQuote = data,
      err => this.logError(err),
      () => console.log('Random Quote Complete')
    );
}

logError(err) {
  console.error('There was an error: ' + err);
}
```

The `getRandomQuote` method starts off looking pretty familiar--we do an `http.get` request by passing in a URL as an argument. Remembering `$http` from Angular 1.x, this is where we would tap into the promise that gets returned by using `.then`, but as you can see here, we're doing something pretty different.

As was mentioned earlier, **HTTP calls in Angular 2** return observables, so we need to use RxJS methods to operate on them. The first thing we do is map the values that are returned as text, since our call to the `api/random-quote` endpoint returns text. If we were expecting a JSON response, we would call `res.json()` instead. After this, we need to **subscribe** to it so that we can **observe** values that are returned.

<include src="TweetQuote" quoteText="HTTP calls in Angular 2 return observables, so we need to use RxJS methods to operate on them."/>

An observable subscription takes three functions to handle what happens as the stream is observed. The first function is the **next** case, or what happens when the HTTP call is successful. If the call is successful, we're saying that the data returned should be put on a property `randomQuote` so it can be displayed in the view. The second function is the **error** case, and in our example we are logging any error messages to the console by calling our `logError` method. Finally, the third function defines what happens once the call is **complete**, and here we are simply logging out the things are finished.

Let's test that out to make sure it works.

![angular2 http $http example](https://images.ctfassets.net/23aumh6u8s0i/3OP3Z3TjFP2iMFkiVN3XAD/b75a0e2b9229dc18e43fee1ff97be2fc/angular2-http-1)

## POST Request with Modified Content Type

Our `authenticate` method will need to make a `POST` request to the back end and specify the content type so that we can send our credentials. For this, we'll use `Headers`.

```js
// app.ts

...

class CredentialsModel {
  username: string;
  password: string;
}

...

authenticate(data) {
  var username = data.credentials.username;
  var password = data.credentials.password;

  var creds = "username=" + username + "&password=" + password;

  var headers = new Headers();
  headers.append('Content-Type', 'application/x-www-form-urlencoded');

  this.http.post('http://localhost:3001/sessions/create', creds, {
    headers: headers
    })
    .map(res => res.json())
    .subscribe(
      data => this.saveJwt(data.id_token),
      err => this.logError(err),
      () => console.log('Authentication Complete')
    );
}

saveJwt(jwt) {
  if(jwt) {
    localStorage.setItem('id_token', jwt)
  }
}

...
```

The `authenticate` method accepts `data` that is passed down from the view when the form is submitted. We're grabbing the username and password from it and making a `creds` string in the form that the server expects.

We need to say that the content type should be `application/x-www-form-urlencoded` and this can be done by appending a header onto our `headers` instance. Then we simply pass this as a header in the options object when we make the `POST` request. From here, the returned observable is handled in the same way that we saw in the `GET` request, but this time the response is JSON, so we use `res.json()`. We also call the `saveJwt` method and pass it the token that is received to save it in local storage.

## GET Request with Authorization Header

Now that we know how to modify headers, sending the JWT as an `Authorization` header is simple.

```js
// app.ts

...

getSecretQuote() {

  var jwt = localStorage.getItem('id_token');
  var authHeader = new Headers();
  if(jwt) {
    authHeader.append('Authorization', 'Bearer ' + jwt);      
  }

  this.http.get('http://localhost:3001/api/protected/random-quote', {
    headers: authHeader
  })
  .map(res => res.text())
  .subscribe(
    data => this.secretQuote = data,
    err => this.logError(err),
    () => console.log('Secret Quote Complete')
  );

}

...

```

We can check this in the browser to make sure our call to the protected endpoint works.

![angular2 http $http observables rxjs](https://images.ctfassets.net/23aumh6u8s0i/7MDfOrK8h8fqU4MkXg98Zq/aa05c56ac6ec9575ea934901e66c3e14/angular2-http-2)

## What Can We Do with Observables?

You might be wondering why Http doesn't just return promises like it used to, so we can stick to our familiar methods for resolving HTTP calls. The fact of the matter is that we can do much more with observables than promises. With observables, we have a [whole bunch of operators](https://github.com/Reactive-Extensions/RxJS/blob/master/doc/gettingstarted/categories.md) to pull from, which let us customize our streams in nearly any way we want.

If you haven't worked with observables before, you can get an idea of how they work in our recent post on [Authenticable Observables](https://auth0.com/blog/2015/09/10/jwt-authentication-with-observables/).

It should be noted that the [Angular team is still deciding](https://github.com/angular/angular/issues/4390) on the best way of implementing the RxJS operators with Http, which means these operators aren't all available for use just yet.

We can get a taste for how they work by plugging in some simple operators. For example, in our `GET` call to `api/random-quote`, we can attach a filter.

```js
// app.ts

...

getRandomQuote() {
  var count = 0;
  this.http.get('http://localhost:3001/api/random-quote')
    .map(res => res.text())
    .filter(x => x.length > 100)
    .subscribe(
      data => this.randomQuote = data,
      err => this.logError(err),
      () => console.log('Random Quote Complete')
    );
}

...
```

Now only quotes with a length greater than 100 characters will come through. If we click the "Get Random Quote" button a few times, we see it at work.

We can also delay our subscription if we want. Here we wait two seconds before printing the quote to the screen.

```js
// app.ts

...

  .map(res => res.text())
  .delay(2000)
  .subscribe(
    data => this.randomQuote = data,
    err => this.logError(err),
    () => console.log('Random Quote Complete')
  );

...
```

While that might not be the most useful, what we will really benefit from once Http is solidified are operators like `retry`. If we were expecting network connectivity issues, we could define a number of times to retry the request.

```js
// app.ts

...

  .retry(3)
  .map(res => res.text())
  .subscribe(
    data => this.randomQuote = data,
    err => this.logError(err),
    () => console.log('Random Quote Complete')
  );

...
```

Another benefit of observables is that they can be cancelled. This can be useful for situations where HTTP requests are going on for a long time, perhaps to an unresponsive server somewhere. This is something that isn't easily done with promises, and something that the [Fetch API has yet to implement](https://github.com/whatwg/fetch/issues/27).


## Aside: Using Angular with Auth0

Auth0 issues [JSON Web Tokens](http://jwt.io) on every login for your users. This means that you can have a solid [identity infrastructure](https://auth0.com/docs/identityproviders), including [single sign-on](https://auth0.com/docs/sso/single-sign-on), user management, support for social identity providers (Facebook, Github, Twitter, etc.), enterprise identity providers (Active Directory, LDAP, SAML, etc.) and your own database of users with just a few lines of code. We implemented a tight integration with Angular 1. Angular 2 integration is coming as soon as it's on Beta! You can read the [documentation here](https://auth0.com/docs/client-platforms/angularjs) or you can checkout the [SDK on Github](https://github.com/auth0/auth0-angular).

<img src="https://images.ctfassets.net/23aumh6u8s0i/2rne3k2iZ3EtRRpLuafLhM/67acd166eb2dcacba5d573863f1b0b06/angular-and-auth0" style="border: 1px solid #ccc;padding: 10px;"/>

## Wrapping Up

**HTTP requests in Angular 2** definitely look different than they did in Angular 1.x, but with the change comes a big boost in capability. Having requests return observables is great because we will be able to use RxJS's operators to get the returned streams behave the way we like. We'll be able to use operators like `retry` to automatically start a request again if there are network issues.

In this tutorial we saw how Http can be used to make `GET` and `POST` requests, but we can also use other HTTP verbs like `PUT`, `DELETE`, and `PATCH`. We also saw how we can customize the headers we send with the `Headers` class.

As with Angular 2 in general, Http is always going through changes. The Angular team keeps a very good [backlog of Http issues and feature implementations](https://github.com/angular/angular/issues/2793), which is a good place to keep updated on how Http progresses.


Using Angular $Http and Angular 2 Http - Angular 2 Series Part 3

Learn about Angular 2's new Dependency Injection system and how to use models to organize your app.

---

**TL;DR:** Domain models are important for defining and enforcing business logic in applications and are especially relevant as apps become larger and more people work on them. In this article, we show how this can be done in an Angular 2 app by moving logic out of the component and into a model. We also cover how to inject model classes using Angular 2's new Dependency Injection system. Check out the [repo](https://github.com/auth0/angular2-models-di) for the article to see the code.

This is the second part of our Angular 2 series. You can also check out the first part about [Angular 2 pipes](https://auth0.com/blog/2015/09/03/angular2-series-working-with-pipes/).

---

> Auth0's Angular 2 series brings you tutorials on how to implement the latest features from the framework using the most recent Alpha release at the time of writing.

As applications grow in size, it becomes increasingly important that they be well organized with a solid structure in place. This is especially critical as increasing numbers of developers are added to the team. Application architecture should also strongly focus on the business rules that govern the application and protect sensitive methods from being exposed where they shouldn't be.

<include src="TweetQuote" quoteText="As applications grow in size, it becomes important that they be well organized with a solid structure in place"/>

At the same time, it is important that we keep our applications DRY and maintainable by moving logic out of components themselves and into separate classes that can be called upon. A modular approach such as this makes our app's business logic reusable.  

One way we can achieve this type of structure in Angular 2 applications is by using models to organize our business logic. Whereas the term "model" in Angular has typically been used to refer to the View-Model, what we're discussing here is the domain model-or the set of rules and business logic that an application implements for it to adhere to the organization's needs.

The term "domain model" is, of course, a generic one. Domain models are relevant in any kind of application. In this tutorial, we will see how we can abstract business logic to a model in an Angular 2 app and use the new **Dependency Injection (DI)** system to call upon these models. We will also explore the DI system's features and various ways it can be used.

## Getting Started with an Angular 2 app

We'll be writing our app in TypeScript, but everything will work just fine in ES6. If you'd like an Angular 2 starter app in ES6, checkout [Pawel Kozlowski's](https://twitter.com/pkozlowski_os) [ng2-play](https://github.com/pkozlowski-opensource/ng2-play/) repo.

Our sample app will take a user's details as input and use a model to handle those values. Let's start with a simple component called `UsersAppComponent`.

```js
// app.ts

/// <reference path="typings/_custom.d.ts" />

import {Component, View, bootstrap, bind, FORM_DIRECTIVES} from 'angular2/angular2';
import {Inject} from 'angular2/di';

@Component({
  selector: 'users'
})
@View({
  // Form directives to be used in the template
  directives: [FORM_DIRECTIVES],
  templateUrl: 'userTemplate.html'
})

class UsersAppComponent {

  constructor() {}

}

bootstrap(UsersAppComponent);
```
Our template has some simple inputs for the user to provide their information, including checkboxes for them to select which programming languages they know.

```html
  

  <form role="form" #form="form" (ng-submit)="submit(form.value)">
    
    <input type="text" placeholder="Enter your name" [(ng-model)]="user.name">
    <input type="text" placeholder="Enter your email" [(ng-model)]="user.email">
    <h3>Languages</h3>
    <input type="checkbox" [(ng-model)]="user.javascript">JavaScript
    <input type="checkbox" [(ng-model)]="user.ruby">Ruby
    <input type="checkbox" [(ng-model)]="user.php">PHP
    <button>Submit</button>
  </form>
```

## Handling User Data

For our app, we'll want to take the user's input to see how it can be handled with a model. For simplicity, we'll just log the info to the console in these examples, but you would typically be doing HTTP requests to send the user data off to a server to be persisted.

We could set up a simple `User` class that acts as a model for our data and have some additional methods in our `UsersAppComponent` that act upon the form data. We can do this right within our component, but as will become evident later, there are some drawbacks to this. Let's see what it would look like for now. The class arrangement will be:

![angular2 models dependency injection](https://images.ctfassets.net/23aumh6u8s0i/6o3tJOtNbC96nlsVPqjeLs/a54fc2b4d2955d66f1b84410801b03d6/classes-at-start)

```js
// app.ts

...

class User {
  name: string;
  email: string;
  rating: number;
}

@Component({
  selector: 'users'
})
@View({
  directives: [FORM_DIRECTIVES],
  templateUrl: 'userTemplate.html'
})

class UsersAppComponent {

  // We instantiate the user class.
  user = new User();

  submit(userInfo) {
    // HTTP request would go here
    console.log(
      this.user.name,
      this.user.email,
      this.calculateRating(this.user)
    );
  }

  // Method to calculate the user's points
  calculateRating(userInfo) {
    var rating = 0;
    if(userInfo.javascript) {
      rating += 30;
    }
    if(userInfo.ruby) {
      rating += 20;
    }
    if(userInfo.php) {
      rating += 50;
    }
    return rating;
  }
}

...
```
We have two-way data binding set up on our form inputs, and they are bound to the instance of our `User` model. The `submit` method in our component's constructor logs the all the data to the console, including a calculation for the user's rating that it runs with the `calculateRating` method. How the heck did PHP get to be worth 50 points? I guess we'll never know.

## Improving the Model

While this approach works sufficiently well when an application is small, the way we have set things up does have a few drawbacks:

1. The `User` class isn't enforcing which values should be present or not. This can have implications if some operation downstream expects certain values to always be present.
2. The model doesn't have methods of its own to handle the calculation of the user's rating or the submission of the data. What if we wanted to have this same functionality in another of our app's components? We would need to duplicate the code in those other components.
3. While `calculateRating` is trivial in this example, what if we had some important and sensitive method with business logic that is meant only for specific circumstances? We need a way to be certain that such methods can't be used in places they're not supposed to be.
4. We currently have no ability to potentially share models with a JavaScript backend.

Let's see how we can tackle some of these issues. We'll start by moving the model to its own file. We'll eventually want to end up with classes that look more like this:

![angular2 models dependency injection](https://images.ctfassets.net/23aumh6u8s0i/2AZ4VJnqch6kcfIL6DlYlv/6fc64e402d51f1a5e9c12975324c0ac3/classes-at-end)


```js
// models/user.ts

export class User {
  name: string;
  email: string;
  rating: number;

  constructor(userInfo:any) {
    this.name = userInfo.name;
    this.email = userInfo.email;
    this.rating = this.calculateRating(userInfo);
  }

  private calculateRating(userInfo) {
    var rating = 0;
    if(userInfo.javascript) {
      rating += 30;
    }
    if(userInfo.ruby) {
      rating += 20;
    }
    if(userInfo.php) {
      rating += 50;
    }
    return rating;
  }

  save() {
    // HTTP request would go here
    console.log(this.name, this.email, this.rating);
  }
}
```

We're now using a constructor in our `User` method, which will set the values for `name`, `email`, and `rating` when the class is instantiated. We've got our `calculateRating` method in our class now, along with a `save` method to take care of making an HTTP request to save the data.

In our template, let's switch from using `ng-model` for two-way data binding to `ng-control` to get the form values when the form is submitted.

```html
  
  <form role="form" #form="form" (ng-submit)="submit(form.value)">
    <input type="text" placeholder="Enter your name" ng-control="name">
    <input type="text" placeholder="Enter your email" ng-control="email">
    <input type="checkbox" ng-control="javascript">JavaScript
    <input type="checkbox" ng-control="ruby">Ruby
    <input type="checkbox" ng-control="php">PHP
    <button>Submit</button>
  </form>
```

We can now modify the `UsersAppComponent` to instantiate and save a new instance of the model when the form is submitted.

```js
// app.ts

...

import {User} from 'models/user';

...

class UsersAppComponent {

  submit(userInfo) {

    // Instantiate and save when the form is submitted
    this.user = new User(userInfo);
    this.user.save();

  }
}

...

```

The model and the methods that it relies on are now in the same spot and can be used in other parts of the application as well. In the model, we specified that we want `calculateRating` to be `private`, but as it stands, we would still be able to gain access to it from outside the `User` model. This is part of [TypeScript's design](http://typescript.codeplex.com/discussions/451129), but we can put a workaround in if we really wanted to protect `calculateRating`. Although it might not work as an architectural approach in every situation, we could define `calculateRating` as a function within the class constructor, which would prevent it from being accessed elsewhere. The downside here is that the function is not available to other methods within the class.

```js
// models/user.ts

...

constructor(userInfo:any) {

  this.name = userInfo.name;
  this.email = userInfo.email;
  this.rating = calculateRating(userInfo);

  // Function is only available inside the constructor
  // when the logic really needs to be protected.
  function calculateRating(userInfo) {...}
}

...
```

## Moving to Factories

We've seen how we can instantiate a new model and access methods on it, but what if we wanted to take the factory approach? In this approach, instead of instantiating the model directly in our components, we would call a method like `create` on the factory. As applications grow and classes become increasingly complex, this can have certain advantages, especially for maintainability. For example, if we wanted to change the name of a class that gets instantiated, the factory approach allows us to make a change solely to the factory itself and not all the instantiation points around the app.

This is also where Angular 2's Dependency Injection comes in, as we'll need to inject the factory to make use of it.

```js
// models/userFactory.ts

import {User} from './user';

export class UserFactory {

  // Uses the User model to create a new User
  create(userInfo:any) {
    return new User(userInfo);
  }

}
```

We'll need to inject the `UserFactory` into our component's constructor. Angular 2 comes with an `@Inject` decorator, which is used to attach metadata to the component. We also need to include `UserFactory` in an array when the app is bootstrapped so that it is included as a binding.

```js
// app.ts

...

import {UserFactory} from 'models/userFactory';

...

class UsersAppComponent {
  userName: string;
  userRating: number;
  rating: number;

  // We inject the UserFactory
  constructor(@Inject(UserFactory) UserFactory) {  
    this.UserFactory = UserFactory;
  }

  ...
}

// We bind the UserFactory when the component is bootstrapped
bootstrap(UsersAppComponent, [UserFactory]);

```

With `this.UserFactory` pointing to the `UserFactory`, we can now make use of its methods. Let's adjust the `submit` method to use the factory.

```js
// app.ts

...

submit(userInfo) {
  this.user = this.UserFactory.create(userInfo);
  this.user.save();
}

...


```

Now when the user submits the form, `create` and `save` are called with the form data.

We can also use the model approach to get the data for the user that just submitted the form. For example, we could add a `get` method to the `User` class that returns (or in this case logs to the console) the user's data.

```js
// models/user.ts

...

get() {
  console.log(this.name, this.email, this.rating);
}

...
```

Then within the component we can create a `getUser` method to retrieve it.

```js
// app.ts
...

getUser() {
  this.user.get();
}

...
```

## More on Dependency Injection

We used the `@Inject` decorator to bring in `UserFactory` above; however, TypeScript also allows us to use type annotations, which means the constructor can be written as:

```js
// app.ts

...

constructor(UserFactory: UserFactory) {...}

...
```

The array syntax we used to bind `UserFactory` to our component is the shorthand way of doing it. We can also explicitly state what we want to bind to, which gives us the option of binding to other classes. For example, we could bind `User` to `UserFactory` directly.

```js
// app.ts

...

// The UserFactory can be bound to another name, in this case, User
bootstrap(UsersAppComponent, [bind(User).toClass(UserFactory)]);

...
```

With this, `UserFactory` becomes `User` when used in our component.

## Aside: Using Angular with Auth0

Auth0 issues [JSON Web Tokens](http://jwt.io) on every login for your users. This means that you can have a solid [identity infrastructure](https://auth0.com/docs/identityproviders), including [Single Sign On](https://auth0.com/docs/sso/single-sign-on), User Management, support for Social (Facebook, Github, Twitter, etc.), Enterprise (Active Directory, LDAP, SAML, etc.) and your own database of users with just a few lines of code. We implemented a tight integration with Angular 1. Angular 2 integration is coming as soon as it's on Beta! You can read the [documentation here](https://auth0.com/docs/client-platforms/angularjs) or you can checkout the [SDK on Github](https://github.com/auth0/auth0-angular).

<img src="https://images.ctfassets.net/23aumh6u8s0i/4PnRDegulvaccUIfNyaAtn/8342312355dc6af44a69c07c66f58be7/pub_w_1219_amp_h_559" style="border: 1px solid #ccc;padding: 10px;"/>

## Wrapping Up

It's important that thought be given to how applications are architected so that they are easier to maintain and can be collaborated on by more developers as team sizes grow. It's also important to protect business logic and keep sensitive methods from being accessed outside the class to which they belong. These effects can be achieved by moving logic into models.

Angular 2 gives us a new Dependency Injection system that allows us to inject classes into our components easily. We had a brief look at how the new DI system works, but for a more thorough overview, we recommend you check out [Pascal Precht](https://twitter.com/PascalPrecht)'s post on [Dependency Injection in Angular 2](http://blog.thoughtram.io/angular/2015/05/18/dependency-injection-in-angular-2.html).

Angular 2 Series - Part 2: Domain Models and Dependency Injection

Learn how to implement pipes (formerly known as filters) in your Angular 2 apps

---

**TL;DR:** In this first installment of the Angular 2 series, we take a look at **pipes** which replace filters from Angular 1.x. Many of the filters from Angular 1.x carry over to pipes, but we also get some new ones. Check out [the repo](https://github.com/auth0/angular2-pipes) for this tutorial to see the pipes in action and to learn how to create your own custom pipes. To see an example of a full Angular 2 app, read Auth0's tutorial on [creating your first Angular 2 app](https://auth0.com/blog/2015/05/14/creating-your-first-real-world-angular-2-app-from-authentication-to-calling-an-api-and-everything-in-between/).

---

> Auth0's Angular 2 series brings you tutorials on how to implement the latest features from the framework using the most recent Alpha release at the time of writing.

## From Filters to Pipes

AngularJS 1.x filters are helpful for formatting output in our templates. With Angular 2, we get this same great feature, but they are now called **pipes**. At the time of this writing, Angular 1.x and Angular 2 have an equal number of filters to pipes, but there isn't direct crossover. The following table shows a comparison:

<table class="table">
<thead>
<tr>
<th> Filter/Pipe Name </th>
<th style="text-align:center;"> Angular 1.x </th>
<th style="text-align:center;"> Angular 2 </th>
</tr>
</thead>
<tbody>
<tr>
<td> currency         </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;"> ✓  </td>
</tr>
<tr>
<td> date             </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;"> ✓  </td>
</tr>
<tr>
<td> uppercase        </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;"> ✓  </td>
</tr>
<tr>
<td> json             </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;"> ✓  </td>
</tr>
<tr>
<td> limitTo          </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;"> ✓  </td>
</tr>
<tr>
<td> lowercase        </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;"> ✓  </td>
</tr>
<tr>
<td> number           </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;">           </td>
</tr>
<tr>
<td> orderBy          </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;">           </td>
</tr>
<tr>
<td> filter           </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;">           </td>
</tr>
<tr>
<td> async            </td>
<td style="text-align:center;">             </td>
<td style="text-align:center;"> ✓  </td>
</tr>
<tr>
<td> decimal          </td>
<td style="text-align:center;">             </td>
<td style="text-align:center;"> ✓  </td>
</tr>
<tr>
<td> percent          </td>
<td style="text-align:center;">             </td>
<td style="text-align:center;"> ✓  </td>
</tr>
</tbody>
</table>

In this article, we will explore the features provided by some of Angular 2's pipes that aren't comparable to Angular 1.x filters. We'll also learn how to create a custom pipe and use it in our templates.

You'll need to have an Angular 2 sandbox set up for this tutorial. A good one to get started with is [ng2-play](https://github.com/pkozlowski-opensource/ng2-play) by [Pawel Kozlowski](https://twitter.com/pkozlowski_os).

## Basic Pipes

Many of the pipes provided by Angular 2 will be familiar if you've worked with filters in Angular 1.x. Pipes are accessed in our templates in the same way that filters were--with the "pipe" character `|`. For example, we can use the `date` pipe to transform a date object in any way we like by providing it with an argument for formatting:

```js
// app.ts

/// <reference path="typings/angular2/angular2.d.ts" />

import {Component, View, bootstrap} from 'angular2/angular2';

@Component({
  selector: 'pipes'
})
@View({
  templateUrl: 'pipesTemplate.html'
})
// Component controller
class PipesAppComponent {
  date: Date;

  constructor() {
    this.date = new Date();
  }
}

bootstrap(PipesAppComponent);
```

We pointed our `@View` decorator to a `templateUrl` in which we make use of the `date` pipe:

```html
  
  <h1>Dates</h1>
  
  <p>{{ "{{date | date:'mediumDate'" }}}}</p>
  
  <p>{{ "{{date | date:'yMMMMd'" }}}}</p>
  
  <p>{{ "{{date | date:'shortTime'" }}}}</p>
```

![angular2](https://images.ctfassets.net/23aumh6u8s0i/37BF7NE33IEQ0xMA2lAHlk/8ab9d0d3f3f2d9be6ccb3cc8f602f2ae/angular2-pipes-1-1)

## New Pipes

The `decimal` and `percent` pipes are new in Angular 2. These take an argument that describes the "digit info" that should be used--that is, how many integer and fraction digits the number should be formatted with. The argument we pass for formatting follows this pattern: `{minIntegerDigits}.{minFractionDigits}-{maxFractionDigits}`.

**Note:** The `decimal` pipe is accessed using `number` in our templates.

```js
// app.ts

...

@View({
  templateUrl: 'pipesTemplate.html'
})

class PipesAppComponent {
  grade: number;
  rating: number;

  constructor() {
    this.grade = 0.99;
    this.rating = 9.1243;
  }
}

...
```

```html
  <h1>Decimals/Percentages</h1>
  
  <p>{{ "{{grade | percent:'.2'" }}}}</p>
  
  <p>{{ "{{rating | number:'2.1-2'" }}}}</p>
```
![angular2](https://images.ctfassets.net/23aumh6u8s0i/4XFENZUIJ6yoSfLSPVdEJt/e69dc9dc5ab1824a6ef9c193d2215124/angular2-pipes-1-2)

## The Async Pipe

Angular 2 provides a special pipe known as `async`, which allows us to bind our templates directly to values that arrive asynchronously. This ability is great for working with promises and observables. To see how this works, we'll create a simple promise and have it resolve with a string.

<include src="TweetQuote" quoteText="Angular 2's async allows us to bind our templates directly to values that arrive asynchronously"/>

```js
// app.ts

...

@Component({
  selector: 'pipes',
  changeDetection: 'ON_PUSH'
})
@View({
  templateUrl: 'pipesTemplate.html',
})

class PipesAppComponent {
  promise: Promise;

  constructor() {
    this.promise = new Promise(function(resolve, reject) {
      setTimeout(function() {
        resolve("Hey, I'm from a promise.");
      }, 2000)
    });
  }
}

...
```

```html
  
  <h1>Async</h1>
  <p>{{ "{{ promise | async" }}}}</p>

```

After a 2 second delay, the value from the resolved promise will be displayed on the screen.

![angular2](https://images.ctfassets.net/23aumh6u8s0i/5TsNZysQufm6z3ja3Fb7vA/e349949ba860e421ab91e22207fbcf35/angular2-pipes-1-3)


## Custom Pipes

Before Alpha 35, we had to configure our custom pipes with a `pipes` object. However, we can now define a pipe with the decorator `@Pipe` and use it by adding a `pipes` property to the `@View` decorator with the name of the pipe class. This makes it easier and more convenient to register our custom pipes.

```js
// app.ts

import {Component, View, bootstrap, Pipe, PipeTransform} from 'angular2/angular2';

...

// We use the @Pipe decorator to register the name of the pipe
@Pipe({
  name: 'tempConvert'
})
// The work of the pipe is handled in the tranform method with our pipe's class
class TempConvertPipe implements PipeTransform {
  transform(value: number, args: any[]) {
    if(value && !isNaN(value) && args[0] === 'celsius') {
      var temp = (value - 32) * 5/9;
      var places = args[1];
      return temp.toFixed(places) + ' C';       
    }

    return;
  }
}

...

@View({
  templateUrl: 'pipesTemplate.html',

  // We can pass the pipe class name into the pipes key to make it usable in our views
  pipes: [TempConvertPipe]
})

class PipesAppComponent {
  temperature: number;

  constructor() {
    this.temperature = 85;
  }
}
```

```html
  <h1>Custom Pipes - Convert Temperature</h1>
  
  <h3>Fahrenheit: {{ "{{temperature + ' F'" }}}}</h3>
  
  <h3>Celsius: {{ "{{temperature | tempConvert:'celsius':1" }}}}</h3>
```
We use the `transform` method to do any logic necessary to convert the `value` that is being passed in. We can get ahold of the arguments array as the second parameter and pass in as many as we like from the template. As you can see here, we check the type of conversion that we want (e.g., Fahrenheit to Celsius), convert the `value` passed in, and then return the converted value to the number of decimal places specified in the second argument of the pipe.

As mentioned above, we need to provide an array to the `pipes` property in the `@View` decorator to use the new pipe.

![angular2](https://images.ctfassets.net/23aumh6u8s0i/4CierHg40QFc5hYSp4qlCl/9354d43b0c97946d05ac5a032c5b5f9e/angular2-pipes-1-4)

## Aside: Using Angular with Auth0

Auth0 issues [JSON Web Tokens](http://jwt.io) on every login for your users. This means that you can have a solid [identity infrastructure](https://auth0.com/docs/identityproviders), including [Single Sign On](https://auth0.com/docs/sso/single-sign-on), User Management, support for Social (Facebook, Github, Twitter, etc.), Enterprise (Active Directory, LDAP, SAML, etc.) and your own database of users with just a few lines of code. We implemented a tight integration with Angular 1. Angular 2 integration is coming as soon as it's on Beta! You can read the [documentation here](https://auth0.com/docs/client-platforms/angularjs) or you can checkout the [SDK on Github](https://github.com/auth0/auth0-angular).

<img src="https://images.ctfassets.net/23aumh6u8s0i/4PnRDegulvaccUIfNyaAtn/8342312355dc6af44a69c07c66f58be7/pub_w_1219_amp_h_559" style="border: 1px solid #ccc;padding: 10px;"/>

## Wrapping Up

Angular 2 provides some great pipes that carry over well from the filters we are used to in Angular 1.x. We also get some new pipes that give us special functionality, such as the `async` pipe, which binds our templates to asynchronous resources. It's also easy to create our own pipes via the `@Pipe` decorator and the `pipes` key in our `@View` decorators.

You can find the code for this tutorial on [GitHub](https://github.com/auth0/angular2-pipes).