先日、学生向けに Todo ワークショップを開催した時の話です。
Angular1 のように`ngFor`と Pipe を組み合わせて、リストのソート機能をつくろうとしたところ、初め上手く動かせませんでした。
StackOverFlow で解決策を見つけてなんとか動かすことはできたのですが、腑に落ちず後日改めて調べたところ、Pipe を使う上で知っておくべき事を知らなかったことに気づきました。

今回は Pipe を使う上で、これだけは最低限知っておくべき内容について紹介します。



## tl;dr

- 開発者が知るべきたった 1 つのことは、**「Angular2 の Pipe には`pure`と`impure`の 2 種類がある」**ということ。
- `pure`Pipe が想定通りのタイミングで動作しない時は、`impure`を使ってみるのも手。
- ただし、Pipe でフィルタやソートを行うことはパフォーマンス上の懸念があるので、Component にて行うことを推奨します。

英語が読める人は本家のドキュメントを読んでください。

- [Angular | Pipes - ts](https://angular.io/docs/ts/latest/guide/pipes.html)

## `pure`と`impure`の違い

まず、Pipe には`pure`と`impure`の 2 つあるのですが、デフォルトは`pure`です。2 つの違いについて一言で表すとそれは**「Pipe が評価されるタイミング(反応する change detection)」**の違いです。下にその違いについて示します。

- pure
  - プリミティブ型(String, Number, Boolean, Symbol)の値が変わった時
  - オブジェクト型(Date, Array, Function, Object)の参照が変わった時
- impure
  - 常に評価

ここで大事なのは`pure`では、オブジェクトや配列内部の変更は無視してしまうということです。(このことを本家では`pure change`と表現しています。)
これは常に Deep check をすることを避け、パフォーマンスを向上させるために必要なことですが、うっかりこの事を知らないと Pipe が想定通りの動きをしない事態が容易に起こりえます。

## `impure`Pipe の作り方

`impure`Pipe を作るためには、`@Pipe`宣言の部分でプロパティに`pure: false`を指定することでできます。

```ts
@Pipe({
  name: 'impurePipe',
  pure: false
})
export class MyImpurePipe {}
```

非常に簡単なのですが、このとき「`pure`って何？」となるわけです。

### まとめ

では`impure`Pipe をガンガン使っていいのでしょうか？

本家のドキュメントに次の一文がありました。

> No FilterPipe or OrderByPipe

Pipe でフィルタやソートは行わないでくれと行っています。本家ではこれらの機能を Component 側に移動することを推奨しています。
理由の 1 つとしてフィルタやソートを Pipe で行うために、必ず処理対象のオブジェクトの参照が必要となり、非常にコストが高い処理となり易いことが挙げられます。

Angular1 の時代から`ng-repeat`と Filter を組み合わせてた場合、うっかり `n×n`の計算量となってしまい、パフォーマンス上の問題を出すことが多々ありました。
Angular2 でも同様に、`ngFor`と`impure`Pipe をうっかり組み合わせることは避けた方がいいと言えます。

## おまけ

- Todo のワークショップ資料
  - [mitsuruog/angular2-todo-tutorial: TodoApp for Anguar2](https://github.com/mitsuruog/angular2-todo-tutorial)
- (とりあえず)参考にした StackOverFlow の記事
  - [angular2 - How to apply filters to \*ngFor - Stack Overflow](http://stackoverflow.com/questions/34164413/how-to-apply-filters-to-ngfor)
  - NgFor doesn't update data with Pipe in Angular2 - Stack Overflow http://stackoverflow.com/questions/34456430/ngfor-doesnt-update-data-with-pipe-in-angular2

Angular2のPipeを使う上で開発者が知るべきたった1つのこと

Way of httpInterceptor in Angular 2

4/10 に開催された[Angular 2 ハンズオン](http://connpass.com/event/28985/)のチューターとして参加してきました。  
チューターしている合間に、Angular2 での HttpIntercepor のやり方を調べてたので、その辺りを紹介します。



ついでに LT してきました。LT の資料はこちらです。

Angular2 HttpInterceptor Needed  
<https://gist.github.com/mitsuruog/6f7f0ca3f546b245bccdd3ebc14375d8>

## HttpInterceptor とは

`HttpInterceptor`とは、XHR(つまり Ajax)に関連する横断的機能(cross-cutting feature)を分離するためのものです。

Controller などの後続処理から、XHR 通信時に発生する例外処理などを分離して`HttpInterceptor`で一括処理します。
Angular1 では、`HttpInterceptor`を使うことで綺麗に分離することができました。

refs: [AngularJS: API: $http](https://docs.angularjs.org/api/ng/service/$http)

## Angular2 では簡単にはできない

Angular2 でも簡単に実現できると考えていたのですが、思ったより面倒でした。
公式リポジトリの Issue にて実現方法について議論されていました。(めっちゃ長いです)

[RFC: Http interceptors and transformers · Issue #2684 · angular/angular](https://github.com/angular/angular/issues/2684)

## Angualr2 での HttpInterceptor の実現方法

以下の手順で実現できます。

1. `Http`を継承した`CustomHttp`を作成する。
1. `bootstrap`にて、既存の`Http`プロバイダを Ovarride する。

では順に見て行きましょう。

### `CustomHttp`を作成する

まず、`CustomHttp`を作成します。`Http`の API を 1 つ 1 つ Warp します。  
例外が発生した場合は、`catch`で捕捉して private 関数の`handleResponseError`で一括処理させるようにしています。

**custom-http.service.ts**

```ts
import {
  Http,
  ConnectionBackend,
  RequestOptions,
  Request,
  RequestOptionsArgs,
  Response,
} from "angular2/http";
import { Observable } from "rxjs/Observable";

export class CustomHttp extends Http {
  constructor(backend: ConnectionBackend, defaultOptions: RequestOptions) {
    super(backend, defaultOptions);
  }

  request(
    url: string | Request,
    options?: RequestOptionsArgs
  ): Observable<Response> {
    return super
      .request(url, options)
      .catch((res: Response) => this.handleResponseError(res));
  }

  get(url: string, options?: RequestOptionsArgs): Observable<Response> {
    return super
      .get(url, options)
      .catch((res: Response) => this.handleResponseError(res));
  }

  // ...長いので省略

  //
  // Here's to handle error stuff
  //
  private handleResponseError(res: Response) {
    if (res.status === 401) {
      // do something
    } else if (res.status === 500) {
      // do something
    }
    return Observable.throw(res);
  }
}
```

### `Http`を上書きする。

つづいて、`bootstrap`時に`Http`を`CustomHttp`で上書きします。
次のコードは、`provide`を利用して、Angular2 が DI を処理する際にインスタンスを生成する方法を変更しています。

**main.ts**

```ts
import { provide } from "angular2/core";
// RxJS本体のObservableを利用するための設定
import { bootstrap } from "angular2/platform/browser";
import "rxjs/Rx";

import { AppComponent } from "./app.component";
import { CustomHttp } from "./common/services/custom-http.service";

bootstrap(AppComponent, [
  provide(Http, {
    useFactory: (backend: XHRBackend, defaultOptions: RequestOptions) => {
      return new CustomHttp(backend, defaultOptions);
    },
    deps: [XHRBackend, RequestOptions],
  }),
]);
```

## まとめ

Angular2 でも`HttpInterceptor`を実現できそうですが、少し面倒でした。

こちらに`custom-http.service.ts`のコード置いておきます。(しばらくはこのままで使えるはず。。。)

[custom-http.service.ts](https://gist.github.com/mitsuruog/6f7f0ca3f546b245bccdd3ebc14375d8#file-custom-http-service-ts)

> (追記)
> LT では`new Providor()`としていましたが、 [@laco0416](https://twitter.com/laco0416)さんから、
> `Providor`を Warp している`provide`を利用した方が破壊的変更が起きにくいとアドバイスいただき変更しました。ありがとうございます！！

Angular2でHTTP Interceptorを使いたい

3/31 に酒を飲みながら Angular について話す素敵な催し[ng-sake](http://connpass.com/event/27707/)が開催されたので、Angular2 のユニットテストについて話て来ました。



当日のレポートは主催の[らこ](https://twitter.com/laco0416)さんが書いたものを参照ください。

- [ng-sake を開催しました | Angular2 Info](http://ng2-info.github.io/2016/03/31/ng-sake-1-report/)

## 当日の模様

Angular を使い込んでいる人が多かったので、濃い内容の話ばかりでした。

> [やばい、参加者がニッチすぎて面白い](https://twitter.com/mitsuruog/status/715153394558705664)

> [わいわい、がやがや。こういう形式もありだよね。angular に関わる人の熱意を感じる ](https://twitter.com/mitsuruog/status/715160894632828930)

> [ディレクトリ構成が盛り上がってて楽しいｗ](https://twitter.com/mitsuruog/status/715149679609192448)

## 発表内容

私の資料はこちらです。

[Angular 2 unit testing overview](https://www.slideshare.net/mitsuruogawa33/angular-2-unit-testing-overview)

Angular2 は別物になっているので、テスト周りの状況も心配していたのですが、結論としては Angular1 とあまり大差なかったです。

こちらに比較表作ってみました。

[Angular 1 to 2 Quick Reference In unit testing](https://gist.github.com/mitsuruog/9e3e5c2c5d17a15a4c2a)

当日紹介したテストのサンプルコードはこちらです。

<https://github.com/mitsuruog/_angular2-unit-test-sample>

[Angular2 Unit Testing - カバレッジ編 | I am mitsuruog](http://blog.mitsuruog.info/2016/03/how-to-test-angular2-application-coverage.html)で紹介したカバレッジが出る仕組みが入っています。
カバレッジフェチの方は動かして楽しめると思います。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/ng-sake-coverage.png)

## まとめ

Angular2 のテストについては公式のドキュメントが足りていない、かつアップデートが激しいです。
最新の情報をチェックしたい場合、生のコードを読みつつ、本家のリポジトリのテストコードを見るのが一番確実です。

最後に、主催の[らこ](https://twitter.com/laco0416)さん、[83](https://twitter.com/armorik83)さん、本当にありがとうございました。
今後も続くといいなー。

ng-sake #1 でAngular2のテストについて話てきた

Angular2 の実装の方法は記事をよく目にする機会が増えたので、テストについての自分が困らないように調べてみたシリーズ。

今回は XHR が関連するテスト。



> （注意）Angular 2.0.0-beta.9 をベースに話しています。
> E2E テストは protractor がそのまま利用できると思うので、ここでのテストはユニットテストの話です。

## Angular2 Unit Testing

1. [準備](/2016/03/how-to-test-angular2-application-1.html)
1. [基本](/2016/03/how-to-test-angular2-application-basic.html)
1. Mock, Spy の基本(TBD)
1. [DOM のテスト](/2016/03/how-to-test-angular2-application-dom.html)
1. [XHR のテスト](/2016/03/how-to-test-angular2-application-xhr.html)
1. Component のテスト(TBD)
1. Service のテスト(TBD)
1. [Pipe のテスト](/2016/03/how-to-test-angular2-application-pipe.html)
1. Directive のテスト(TBD)
1. [カバレッジ](/2016/03/how-to-test-angular2-application-coverage.html)

## XHR のテスト

XHR 通信が関連するテストについて紹介します。

Angular1 には XHR 通信を行う`$http`サービスがありました。
XHR 通信をテストする場合は、`$http`を Mock する[$httpBackend](https://docs.angularjs.org/api/ngMock/service/$httpBackend)を利用し、実際の XHR 通信を`$httpBackend`でダミーのレスポンスに置き換えてテストを行っていました。

Angular2 にも`MockBackend`という`$httpBackend`と同様の役割のものがありますので、利用方法について紹介します。

- [MockBackend - ts](https://angular.io/docs/ts/latest/api/http/testing/MockBackend-class.html)

## 標準 HTTP の Mock を準備する(beforeEachProviders)

`MockBackend`は`@Injectable`指定されているため、他の Provider と同様に`beforeEachProviders`で呼び出した後に、`inject`でテストコード中に DI して利用する必要があります。

**hero.service.spec.ts**

```ts
describe("HTTPのテスト", () => {
  beforeEachProviders(() => [
    BaseRequestOptions,
    MockBackend,
    provide(Http, {
      useFactory: function (backend, defaultOptions) {
        return new Http(backend, defaultOptions);
      },
      deps: [MockBackend, BaseRequestOptions],
    }),
    HeroService,
  ]);

  // ...省略
});
```

上のコードでは、`Provider`API を利用して、テスト専用の`HTTP`を生成しています。
`Provider`は、Angular2 の中で`@Injecter()`によって DI がされる際にインスタンスの生成方法を指定する API です。

- [Provider - ts](https://angular.io/docs/ts/latest/api/core/Provider-class.html)

ここでは、`dependencies`で`HTTP`が利用している Provider を DI し、`useFactory`内部で新しい`HTTP`インスタンスを作成しています。
インスタンスを作成する際の`backend`に、`dependencies`で指定した`MockBackend`が設定されます。

`dependencies`に設定している各 Provider は、後にダミーのレスポンスを返却する設定を DI するための楔(くさび)だと考えてください。

## ダミーのレスポンスを設定する(inject)

続いてダミーのレスポンスを設定します。

先に生成した`HTTP`がテスト対象の Service に DI されるタイミングで、`inject`を利用して`MockBackend`のレスポンスをダミーで書き換えます。

**hero.service.spec.ts**

```ts
describe("HTTPのテスト", () => {
  // ...省略

  beforeEach(inject([MockBackend], (backend: MockBackend) => {
    const response = new Response(
      new ResponseOptions({
        body: {
          data: [
            { id: "1", name: "mitsuru" },
            { id: "2", name: "ogawa" },
          ],
        },
      })
    );
    backend.connections.subscribe((conn: MockConnection) =>
      conn.mockRespond(response)
    );
  }));

  // ...省略
});
```

ダミーのレスポンスを返却する部分は少しややこしいですが、まずは形から入りましょう。

大事な部分は`ResponseOptions`にダミーのレスポンスを設定する部分です。
上の例では、body の`data`プロパティにダミーのオブジェクトを設定しています。他にも設定できるプロパティが存在するので、詳しくは API を参照してください。

- [ResponseOptions - ts](https://angular.io/docs/ts/latest/api/http/ResponseOptions-class.html)

実際のレスポンスは`MockConnection`を利用して行います。他にも`mockDownload`, `mockError`など使えそうな API があります。

- [MockConnection - ts](https://angular.io/docs/ts/latest/api/http/testing/MockConnection-class.html)

`ResponseOptions`の部分はダミーレスポンス専用のクラスにしておき、テストコードの先頭で import して利用するともっとスッキリすると思います。

## テストを検証する(it)

では XHR 通信が正しく Mock されているか検証します。

その前に、テスト対象の HeroService についてです。
HeroService は、`Hero`のリストを XHR 通信で取得した後に、Observable でラップして返却する(Angular2 的には)シンプルなデータアクセスクラスだとします。

**hero.service.ts**

```ts
@Injectable()
export class HeroService {
  getHeroes(): Observable<Hero[]> {
      return this.http.get(this.URL)
        .map(res => <Hero[]>res.json().data);
    }
}
```

先ほどの設定してダミーレスポンスを実際に検証してみます。

**hero.service.spec.ts**

```ts
describe("HTTPのテスト", () => {
  // ...省略

  it("2件取得できること", inject([HeroService], (testee: HeroService) => {
    testee.getHeroes().subscribe((res: Hero[]) => {
      expect(res.length).toEqual(2);
      expect(res[0].name).toEqual("mitsuru");
    });
  }));
});
```

無事、2 件取得できることが確認できました。
めでたし。めでたし。

## まとめ

HTTP のテストについてでした。

テストの全体像についてはこちらを参考にしてください。

<https://github.com/mitsuruog/_angular2_http>

Unit テスト全般に言えることですが、テストを行うための Mock などの下準備が非常に面倒くさいです。
下準備は定型文的なものが多いため、再利用できるようスニペットなどにしておくことが大事です。

今回は、Service クラスを題材にしたため、テストコードの中で HTTP を置き換えています。
Component など HTTP から遠いレイアーでは、今回のように HTTP を置き換えるのではなく、Service クラスごと Mock 化して`beforeEachProviders`で Service クラスを置き換え方がテストしやすいと思います。

### PR

こちらに初学者のための Minimum starter kit を作成しましたので、ぜひ利用してください。
(もちろんテストもできます！！)

[mitsuruog/angular2-minimum-starter: Minimum starter kit for angular2](https://github.com/mitsuruog/angular2-minimum-starter)

Angular2 Unit Testing - XHRのテスト

Angular2 の実装の方法は記事をよく目にする機会が増えたので、テストについての自分が困らないように調べてみたシリーズ。

今回は DOM が関連するテスト。



> （注意）Angular 2.0.0-beta.9 をベースに話しています。
> E2E テストは protractor がそのまま利用できると思うので、ここでのテストはユニットテストの話です。

## Angular2 Unit Testing

1. [準備](/2016/03/how-to-test-angular2-application-1.html)
1. [基本](/2016/03/how-to-test-angular2-application-basic.html)
1. Mock, Spy の基本(TBD)
1. [DOM のテスト](/2016/03/how-to-test-angular2-application-dom.html)
1. [XHR のテスト](/2016/03/how-to-test-angular2-application-xhr.html)
1. Component のテスト(TBD)
1. Service のテスト(TBD)
1. [Pipe のテスト](/2016/03/how-to-test-angular2-application-pipe.html)
1. Directive のテスト(TBD)
1. [カバレッジ](/2016/03/how-to-test-angular2-application-coverage.html)

## DOM のテスト

DOM のテストについて紹介します。

DOM のような状態が不安定なものをテストする場合、テスト対象の状態を一定に固定するため、`fixture`と呼ばれる土台(仮の DOM)を利用してきました。
Angular2 の DOM のテストでも、これまでと同様に fixture を利用します。

## fixture を準備する(TestComponentBuilder)

まず、テストで利用する fixture を準備します。

Angular2 にはテスト用 fixture を作成するための API`TestComponentBuilder`が準備されています。
`TestComponentBuilder`は、fixture 用の Component を作成して外側から操作・検証する API を提供します。

DOM のテストのおおまかな流れは次のような形です。

```ts
import {
  it,
  describe,
  expect,
  inject,
  injectAsync,
  beforeEach,
  beforeEachProviders,
  TestComponentBuilder
} from 'angular2/testing';
import {Component} from 'angular2/core';

describe('DOMのテスト', () => {

  beforeEachProviders(() => [
    TestComponentBuilder
  ]);

  it('なにかのテスト', injectAsync([TestComponentBuilder], (tcb: TestComponentBuilder) => {
    // ここに実際のテストコードを書く
  }));

});

// fixture用Component
@Component({ selector: 'container' })
class TestComponent { }
```

`TestComponentBuilder`は`@Injectable`指定されているため、他の Provider と同様に`beforeEachProviders`で呼び出した後に、`injectAsync`でテストコード中に DI して利用する必要があります。

続いて、テストで利用する使い捨て Component を作成します。これをテスト用 fixture として利用します。

- [TestComponentBuilder - js](https://angular.io/docs/js/latest/api/testing/TestComponentBuilder-class.html)

## fixture を作成する(overrideTemplate, createAsync)

続いて実際に fixture を作成します。

テスト用 fixture が準備できたので、この Component をテンプレートを上書きして DOM を作成します。

```ts
// itの部分だけ抜粋
it(
  "なにかのテスト",
  injectAsync([TestComponentBuilder], (tcb: TestComponentBuilder) => {
    let template = "<div>Hello Angular2 :)</div>";
    return tcb
      .overrideTemplate(TestComponent, template)
      .createAsync(TestComponent)
      .then((fixture) => {
        // ここに検証コードを書く
      });
  })
);
```

`overrideTemplate`に Component と上書きするテンプレートを渡して、`createAsync`を呼び出すと、実際にテストする fixture が作成されます。

実際には、テンプレートに Component や Directive を含めることが多いかと思います。
Angular1 での`$compile(template)($rootScope)`とほぼ同じものだと考えて大丈夫です。

`TestComponentBuilder`で作成された fixture は`ComponentFixture`クラスなり、次のようなテストで利用する API が準備されています。

- debugElement
  - テスト用の Helper クラス
- componentInstance
  - TestComponent のインスタンス
- nativeElement
  - テスト用 fixture の HTMLElement を表す
- detectChanges()
  - テスト中に Component を変更するために、Component の変更検知サイクルを発火します。

よく利用するものについて紹介します。

- [ComponentFixture - js](https://angular.io/docs/js/latest/api/testing/ComponentFixture-class.html)

## fixture を検証する API(nativeElement)

`nativeElement`はテスト用 fixture の`HTMLElement`を返す API です。
`HTMLElement`は HTML 標準の API であるため、これを利用してテスト用 fixture を検証・操作します。

[HTMLElement - Web APIs | MDN](https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement)

```ts
// itの部分だけ抜粋
it(
  "なにかのテスト",
  injectAsync([TestComponentBuilder], (tcb: TestComponentBuilder) => {
    let template = "<div>Hello Angular2 :)</div>";
    return tcb
      .overrideTemplate(TestComponent, template)
      .createAsync(TestComponent)
      .then((fixture) => {
        let div = fixture.nativeElement.querySelector("div");
        // HTMLElementを検証する
        expect(div).toHaveText("Hello Angular2 :)");
      });
  })
);
```

## fixture を変更する(detectChanges)

`detectChanges()`は、Angular1 の`scope.$digest()`に似ており、強制的に Angular へ変更を検知させる仕組みです。

Angular2 内部では Angular1 の`dirty checking`に代わる独自の変更検知サイクルを持っています。
テストで Click イベントなどの非同期を利用する場合、この変更検知サイクルを発火して Angular2 に変更を検知させる必要があります。

Angular2 の変更検知サイクルについてはこの記事が詳しいです。

- [Change Detection in Angular 2 | Victor Savkin](http://victorsavkin.com/post/110170125256/change-detection-in-angular-2)

次のテストコードは、マウスが当たると文字色が red に変わる Component のテストだと仮定します。

```ts
// ... describeの部分だけ抜粋
describe("DOMのテスト", () => {
  let mouseenter;

  beforeEachProviders(() => [TestComponentBuilder]);

  beforeEach(() => {
    // mouseenterイベントを定義します
    mouseenter = new MouseEvent("mouseenter", {
      view: window,
      bubbles: true,
      cancelable: true,
    });
  });

  it(
    "mouseenterするとredに変わること",
    injectAsync([TestComponentBuilder], (tcb: TestComponentBuilder) => {
      let template = "<div>Hello Angular2 :)</div>";
      return tcb
        .overrideTemplate(TestComponent, template)
        .createAsync(TestComponent)
        .then((fixture) => {
          let div = fixture.nativeElement.querySelector("div");

          // mouseenterイベントを強制的に起こします
          div.dispatchEvent(mouseenter);

          // detectChangesしないと変更が検知されない
          expect(div.style.backgroundColor).toEqual("red"); // => NG
          fixture.detectChanges();
          expect(div.style.backgroundColor).toEqual("red"); // => OK
        });
    })
  );
});
```

## まとめ

DOM についてのテストは以上です。

DOM が関連するテストはやはり面倒ですね。メンバーの習熟度や学習コストを鑑みて、自動テストをしないという選択肢もありだと思います。
テストコードの全体像は、こちらで雰囲気をつかめると思います。

[\_angular2-attribute-directive/highlight.directive.spec.ts at master · mitsuruog/\_angular2-attribute-directive](https://github.com/mitsuruog/_angular2-attribute-directive/blob/master/app%2Fcomponents%2Fhighlight.directive.spec.ts)

今回の例では、検証に fixture の`nativeElement`を利用していましたが、`debugElement`についてはまだ利用用途があまりはっきりとわかっていません。
機会があれば、もう少し掘り下げようかと思います。

- [DebugElement - js](https://angular.io/docs/js/latest/api/core/DebugElement-class.html)

### PR

こちらに初学者のための Minimum starter kit を作成しましたので、ぜひ利用してください。

[mitsuruog/angular2-minimum-starter: Minimum starter kit for angular2](https://github.com/mitsuruog/angular2-minimum-starter)

Angular2 Unit Testing - DOMのテスト

Angular2 の実装の方法は記事をよく目にする機会が増えたので、テストについての自分が困らないように調べてみたシリーズ。

今回は Pipe のテスト。



> （注意）Angular 2.0.0-beta.9 をベースに話しています。
> E2E テストは protractor がそのまま利用できると思うので、ここでのテストはユニットテストの話です。

## Angular2 Unit Testing

1. [準備](/2016/03/how-to-test-angular2-application-1.html)
1. [基本](/2016/03/how-to-test-angular2-application-basic.html)
1. Mock, Spy の基本(TBD)
1. [DOM のテスト](/2016/03/how-to-test-angular2-application-dom.html)
1. [XHR のテスト](/2016/03/how-to-test-angular2-application-xhr.html)
1. Component のテスト(TBD)
1. Service のテスト(TBD)
1. [Pipe のテスト](/2016/03/how-to-test-angular2-application-pipe.html)
1. Directive のテスト(TBD)
1. [カバレッジ](/2016/03/how-to-test-angular2-application-coverage.html)

## Pipe のテスト

Pipe のテストについて紹介します。

Angular2 の Pipe は Angular1 の filter に相当するものです。
Linux コマンドの`|(パイプ)`と同義で、入力内容を Pipe 内で(transform, replace など)処理し、結果を出力する単純なものです。

## Pipe のテストは至ってシンプル

文の区切りの最初の文字を大文字にする Pipe をテストします。

```
例）
abc     => Abc
abc def => Abc Def
```

Pipe のコードはこちらです。

**init-caps.pipe.ts**

```ts
import {Pipe, PipeTransform} from 'angular2/core';

@Pipe({
  name: 'initCaps'
})
export class InitCapsPipe implements PipeTransform {
  transform(value: string): string {
    return value.toLowerCase().replace(/(?:^|\s)[a-z]/g, (m) => m.toUpperCase());
  }
}
```

Pipe は単純な class であるため、テストクラス内でインスタンスを生成してテストします。
至ってシンプルです。

下の例では、`beforeEach`でテスト対象の Pipe を読み込んでテストしています。

**init-caps.pipe.spec.ts**

```ts
import {
  describe,
  it,
  expect,
  inject,
  injectAsync,
  beforeEach,
  beforeEachProviders,
  TestComponentBuilder,
} from "angular2/testing";

import { InitCapsPipe } from "./init-caps.pipe";

describe("Test: InitCapsPipe", () => {
  let testee;

  beforeEach(() => {
    testee = new InitCapsPipe();
  });

  it('"abc"が”Abc”に変換されること', () => {
    expect(testee.transform("abc")).toEqual("Abc");
  });

  it('"abc def"が”Abc Def”に変換されること', () => {
    expect(testee.transform("abc def")).toEqual("Abc Def");
  });

  it('"Abc Def"は変換されないこと', () => {
    expect(testee.transform("Abc Def")).toEqual("Abc Def");
  });
});
```

ただし、Pipe 内部で DI している provider がある場合は、`beforeEachProviders`で読み込んだ後に`inject`で DI する必要があるでしょう。

## まとめ

Pipe のテストは以上です。

Pipe は構造がシンプルなためテストも簡単です。テストの最初にトライするものとしては最適だと思います。
サンプルコードはこちらを参照してください。

[mitsuruog/\_angular2_pipe](https://github.com/mitsuruog/_angular2_pipe)

### PR

こちらに初学者のための Minimum starter kit を作成しましたので、ぜひ利用してください。
(もちろんテストもできます！！)

[mitsuruog/angular2-minimum-starter: Minimum starter kit for angular2](https://github.com/mitsuruog/angular2-minimum-starter)

Angular2 Unit Testing - Pipeのテスト

Angular2 の実装の方法は記事をよく目にする機会が増えたので、テストについての自分が困らないように調べてみたシリーズ。

今回は基本編。



> （注意）Angular 2.0.0-beta.9 をベースに話しています。
> E2E テストは protractor がそのまま利用できると思うので、ここでのテストはユニットテストの話です。

## Angular2 Unit Testing

1. [準備](/2016/03/how-to-test-angular2-application-1.html)
1. [基本](/2016/03/how-to-test-angular2-application-basic.html)
1. Mock, Spy の基本(TBD)
1. [DOM のテスト](/2016/03/how-to-test-angular2-application-dom.html)
1. [XHR のテスト](/2016/03/how-to-test-angular2-application-xhr.html)
1. Component のテスト(TBD)
1. Service のテスト(TBD)
1. [Pipe のテスト](/2016/03/how-to-test-angular2-application-pipe.html)
1. Directive のテスト(TBD)
1. [カバレッジ](/2016/03/how-to-test-angular2-application-coverage.html)

## 基本編

Angular1 は他の JavaScript フレームワークと比較して、テスタビリティ(テストのしやすさを)重視したフレームワークでした。

Angular2 もテスタビリティを重視したフレームワークとなっており、本体の API の中に`angular2/testing`, `angular2/http/testing`, `angular2/router/testing`などテスト専用のものが組み込まれていることからも伺い知ることができます。

## テストフレームワークは Jasmine が基本

テストフレームワークは[Jasmine](http://jasmine.github.io/2.4/introduction.html)を利用します。
これは、`angular2/testing`の中で Jasmine の API を overwrap しているためです。
いまのところ、Angular2 のテストは Jasmine を利用したほうが幸せになれると思います。

## テストクラスの構成

簡単なテストクラス(.ts ファイル)の構成についてです。
ファイル名は慣例としてテスト対象のファイルに`.spec.ts`を付けることが多いです。

```
例）
hero.service.ts
-> hero.service.spec.ts
```

`angular2/testing`の中で Jasmine の API を overwrap しているため、基本的には Jasmine の書き方と同じです。  
テストクラスに含まれる要素は大きく 3 つです。

1. import
1. describe
1. it
1. expect

### テストで利用するモジュールを読み込む(import)

import 部分では、テストで利用するモジュールを読み込みます。  
最低限`angular2/testing`とテストするモジュールを読み込む必要があります。

```ts
import {
  describe,
  it,
  inject,
  injectAsync,
  expect,
  beforeEach,
  beforeEachProviders,
  TestComponentBuilder
} from 'angular2/testing';

import {HeroService} from './hero.service';

...つづく
```

### テストケースをグルーピングする(describe)

複数のテストケースをまとめてグルーピングします。
`describe`はネストできるため、複数のテストケースをグルーピングして見通しを良くすることができます。

```ts
describe("Test: なにかのServiceのテスト", () => {
  describe("Test: 正常系", () => {});

  describe("Test: 異常系", () => {});
});
```

### テストケースを記述する(it)

`it`には実際のテストケースを記述していきます。`it`の中にはテストを検証するためにいくつかの`expect`が含まれます。

```ts
describe("Test: 正常系", () => {
  it("ステータスコードが200であること", () => {});
});
```

### テストを検証する(expect)

`expect`はテストを検証する function です。`matchar`とも呼ばれます。

`expect`は用途に応じていくつか種類があり、`angular2/testing`の`expect`は Jasmine の matchar を overwrap しているため、Jasmine の API はそのまま利用できます。
他にも Angular2 独自で拡張している matchar(NgMatchers)もあります。詳細については割愛します。

[NgMatchers - ts](https://angular.io/docs/ts/latest/api/testing/NgMatchers-interface.html)

```ts
expect(testee).not.toBe(undefined);
```

全体像はこちらで雰囲気を掴んでください。

[app.component.spec.ts](https://github.com/mitsuruog/angular2-minimum-starter/blob/master/app%2Fapp.component.spec.ts)

つづいて Angular2 ならではの機能について紹介します。

## beforeEachProviders

`beforeEachProviders`はテストで利用するモジュールを override する仕組みです。
Angular1 の`$provide`を利用したモジュールの上書きや、[angular.mock.inject](https://docs.angularjs.org/api/ngMock/function/angular.mock.inject)(`_moduleName_`の気持ち悪いやつ)と同等です。

```js
// Angular1($window.locationを上書きする例)
beforeEach(function () {
  module(function ($provide) {
    $window = {
      location: { href: null },
    };
    $provide.value("$window", $window);
  });
});
```

```ts
// Angular2(MyServiceをMyServiceMockで上書きする例)
describe("", () => {
  beforeEachProviders(() => [
    provide(MyService, {
      useClass: MyServiceMock,
    }),
  ]);
});
```

beforeEachProviders では Provider と呼ばれる`Injector`インタフェース(`@Injectable`指定したもの)を持つものや、`@Component`を設定します。(要確認)

[beforeEachProviders - ts](https://angular.io/docs/ts/latest/api/testing/beforeEachProviders-function.html)

## inject, injectAsync

`inject`, `injectAsync`は beforeEachProviders で読み込んだ Provider を`it`や`describe`の中に DI します。
Angular1 での inject と同等のものです。

Angular2 でも`@Injectable`を利用した強力な DI 機能を持っており、異なる`it`のコンテキストの中で利用する Provider を柔軟に選択することができます。

```js
// Angular1
it("should provide a version", inject(function (mode, version) {
  expect(version).toEqual("v1.0.1");
  expect(mode).toEqual("app");
}));
```

```ts
// Angular2
it('should provide a version', inject([mode, version], (mode: string, version: string) => {
  expect(version).toEqual('v1.0.1');
  expect(mode).toEqual('app');
});
```

`injectAsync`は`it`や`describe`の中が非同期の結果を返す場合に利用します。

```ts
it('...', injectAsync([AClass], (object) => {
  return object.doSomething().then(() => {
    expect(...);
  });
})
```

## まとめ

基本編は以上です。

Angular1 と同じ系譜を辿っていることがわかると思いますが、モジュールの override の部分が少し洗練されてきたかなと感じます。

### PR

こちらに初学者のための Minimum starter kit を作成しましたので、ぜひ利用してください。
(もちろんテストもできます！！)

[mitsuruog/angular2-minimum-starter: Minimum starter kit for angular2](https://github.com/mitsuruog/angular2-minimum-starter)

Angular2 Unit Testing - 基本編

Angular2 の実装の方法は記事をよく目にする機会が増えたので、テストについての自分が困らないように調べてみたシリーズ。

今回はカバレッジ編。



> （注意）Angular 2.0.0-beta.9 をベースに話しています。
> E2E テストは protractor がそのまま利用できると思うので、ここでのテストはユニットテストの話です。

## Angular2 Unit Testing

1. [準備](/2016/03/how-to-test-angular2-application-1.html)
1. [基本](/2016/03/how-to-test-angular2-application-basic.html)
1. Mock, Spy の基本(TBD)
1. [DOM のテスト](/2016/03/how-to-test-angular2-application-dom.html)
1. [XHR のテスト](/2016/03/how-to-test-angular2-application-xhr.html)
1. Component のテスト(TBD)
1. Service のテスト(TBD)
1. [Pipe のテスト](/2016/03/how-to-test-angular2-application-pipe.html)
1. Directive のテスト(TBD)
1. [カバレッジ](/2016/03/how-to-test-angular2-application-coverage.html)

## カバレッジ編

> コード網羅率（コードもうらりつ、英: Code coverage ）コードカバレッジは、ソフトウェアテストで用いられる尺度の 1 つである。プログラムのソースコードがテストされた割合を意味する。
> [コード網羅率 - Wikipedia](https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%BC%E3%83%89%E7%B6%B2%E7%BE%85%E7%8E%87)

カバレッジを取得することのメリットは、コードの危ない部分に対して効果的にテストができているか客観的に評価できることです。。
特に HTML 形式のレポートは、コードとテストを実行した部分を重ねて表示することができ、結果を視覚的に見やすくしてくれます。

最近の JavaScript のテストではカバレッジ取得のための環境が整ってきたこともあり、積極的に活用していくべきです。

## karma-coverage でカバレッジを測定する

Karma でカバレッジを取得するためには、プラグインの 1 つである[karma-coverage](https://github.com/karma-runner/karma-coverage)を利用します。
早速、リポジトリの`devDependency`に追加します。

```
npm install karma karma-coverage --save-dev
```

続いて`karma.conf.js`の設定を変更します。

**karma.conf.js**

```js
'use strict';
// Karma configuration

let baseLibs = [...];

module.exports = function (config) {
  config.set({

    // ...省略

    // (1)
    // (*.spec.js, *.mock.js)以外のJavaScriptファイルをカバレッジ測定の対象とします
    preprocessors: {
      "app/**/!(*spec|*mock).js": ['coverage']
    },

    // (2)
    // テスト完了時のreporterにカバレッジ用reporterを設定します
    reporters: ['mocha', 'coverage'],

    // (3)
    // カバレッジ用reporterの出力先, フォーマットを指定します
    // see https://github.com/karma-runner/karma-coverage/blob/master/docs/configuration.md
    coverageReporter: {
      dir : 'report/coverage/',
      reporters: [{
        type: 'html'
      }]
    }

    // ...省略

  })
}
```

テストを実行すると`report/coverage`の直下に HTML 形式のカバレッジレポートが出力されます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/testing-angular2-coverage-1.png)

karma-coverage 内部では、JavaScript のカバレッジ測定ツールとして有名な[istanbul](https://github.com/gotwarlost/istanbul)を利用しています。
HTML レポートでは、ディレクトリやファイルごとにカバレッジを知ることができます。これを見ながらカバレッジの低い部分などに追加のテストを書いていきます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/testing-angular2-coverage-2.png)

コードとテスト実行した部分を重ねあわせて表示することで、テストが不足している部分を容易に発見できます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/testing-angular2-coverage-3.png)

ところがこのままでは、レポートのコードが ts ファイルをトランスパイルした JavaScript ファイルとなっているため、実際に作成した ts ファイル上のどの部分に該当するかが非常に分かりにくいです。

## remap-istanbul で ts ファイルとリンクさせる

先ほどのカバレッジレポートを改良してトランスパイル前の ts ファイルをリンクさせます。リンクさせるには[remap-istanbul](https://github.com/SitePen/remap-istanbul)を利用します。

remap-istanbul とは、ts ファイルをトランスパイルした際に生成される SouceMap(ここでは inline SouceMap)を元に、カバレッジレポートをオリジナルの ts ファイルにリンクさせるツールです。
早速、リポジトリの`devDependency`に追加します。

```
npm install karma remap-istanbul --save-dev
```

続いて`karma.conf.js`の設定を変更します。カバレッジレポートのフォーマットを`html`ではなく`json`に変更します。

**karma.conf.js**

```js
'use strict';
// Karma configuration

let baseLibs = [...];

module.exports = function (config) {
  config.set({

    // ...省略

    // (1)
    // (*.spec.js, *.mock.js)以外のJavaScriptファイルをカバレッジ測定の対象とします
    preprocessors: {
      "app/**/!(*spec|*mock).js": ['coverage']
    },

    // (2)
    // テスト完了時のreporterにカバレッジ用reporterを設定します
    reporters: ['mocha', 'coverage'],

    // (3)
    // カバレッジ用reporterの出力先, フォーマットを指定します
    // see https://github.com/karma-runner/karma-coverage/blob/master/docs/configuration.md
    coverageReporter: {
      dir : 'report/coverage/',
      reporters: [{
        type: 'json',
        subdir : '.',
        file : 'coverage-final.json',
      }]
    }

    // ...省略

  })
}
```

テストを実行すると`report/coverage/coverage-final.json`に JSON 形式のカバレッジレポートが出力されます。
これを remap-istanbul で HTML 形式のレポートに仕立てて行きます。

```
node_modules/.bin/remap-istanbul -i report/coverage/coverage-final.json -o report/coverage/ -t html
```

コマンドを実行すると`report/coverage`の直下に HTML 形式のカバレッジレポートが出力されます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/testing-angular2-coverage-4.png)

今度は ts ファイルとカバレッジレポートがリンクするようになりました。
めでたし。めでたし。

## まとめ

カバレッジの取り方とレポートの表示についてでした。
HTML レポートの出力方法は他にもあると思いますので、いろいろ試してみるといいでしょう。
カバレッジレポートを取得することで、テストが十分でない箇所を明らかにすることができ、つまらないテストにゲーム的な要素が加わってテストを書くことが楽しくなります。

### PR

こちらに初学者のための Minimum starter kit を作成しましたので、ぜひ利用してください。
(もちろんカバレッジも取得できます！！)

[mitsuruog/angular2-minimum-starter: Minimum starter kit for angular2](https://github.com/mitsuruog/angular2-minimum-starter)

Angular2 Unit Testing - カバレッジ編

Angular2 の実装の方法は記事をよく目にする機会が増えたので、テストについての自分が困らないように調べてみたシリーズ。

今回は準備編。



> （注意）Angular 2.0.0-beta.9 をベースに話しています。
> E2E テストは protractor がそのまま利用できると思うので、ここでのテストはユニットテストの話です。

## Angular2 Unit Testing

1. [準備](/2016/03/how-to-test-angular2-application-1.html)
1. [基本](/2016/03/how-to-test-angular2-application-basic.html)
1. Mock, Spy の基本(TBD)
1. [DOM のテスト](/2016/03/how-to-test-angular2-application-dom.html)
1. [XHR のテスト](/2016/03/how-to-test-angular2-application-xhr.html)
1. Component のテスト(TBD)
1. Service のテスト(TBD)
1. [Pipe のテスト](/2016/03/how-to-test-angular2-application-pipe.html)
1. Directive のテスト(TBD)
1. [カバレッジ](/2016/03/how-to-test-angular2-application-coverage.html)

## 準備編

Angular1 の場合と同様に、Angular2 でもユニットテストを実行する前に少し下準備が必要です。
今回は、Angular1 経験者向けに変更点などを紹介します。

サンプルはこちらを参考にしてください。
[mitsuruog/angular2-minimum-starter: Minimum starter kit for angular2](https://github.com/mitsuruog/angular2-minimum-starter)

## Karma ＋ Jasmine の構成はそのまま利用できる

ユニットテストの構成は Angular1 と同じ構成です。

- テストランナー
  - [Karma](https://karma-runner.github.io/0.13/index.html)
- テスティングフレームワーク
  - [Jasmine](http://jasmine.github.io/2.4/introduction.html)

Karma の設定は次のような形です。

**karma.conf.js**

```js
"use strict";
// Karma configuration

let baseLibs = [
  "node_modules/systemjs/dist/system-polyfills.js",
  "node_modules/systemjs/dist/system.js",
  "node_modules/es6-shim/es6-shim.js",
  "node_modules/rxjs/bundles/Rx.js",
  "node_modules/angular2/bundles/angular2-polyfills.js",
  "node_modules/angular2/bundles/angular2.dev.js",
  "node_modules/angular2/bundles/router.dev.js",
  "node_modules/angular2/bundles/http.dev.js",
];

module.exports = function (config) {
  config.set({
    // base path that will be used to resolve all patterns (eg. files, exclude)
    basePath: "",

    // frameworks to use
    // available frameworks: https://npmjs.org/browse/keyword/karma-adapter
    frameworks: ["jasmine"],

    // list of files / patterns to load in the browser
    files: [
      ...baseLibs,
      "node_modules/angular2/bundles/testing.dev.js",
      "karma.shim.js",
      { pattern: "app/**/*.js", included: false },
    ],

    // list of files to exclude
    exclude: [],

    // preprocess matching files before serving them to the browser
    // available preprocessors: https://npmjs.org/browse/keyword/karma-preprocessor
    preprocessors: {},

    // test results reporter to use
    // possible values: 'dots', 'progress'
    // available reporters: https://npmjs.org/browse/keyword/karma-reporter
    reporters: ["mocha"],

    // web server port
    port: 9876,

    // enable / disable colors in the output (reporters and logs)
    colors: true,

    // level of logging
    // possible values: config.LOG_DISABLE || config.LOG_ERROR || config.LOG_WARN || config.LOG_INFO || config.LOG_DEBUG
    logLevel: config.LOG_INFO,

    // enable / disable watching file and executing tests whenever any file changes
    autoWatch: true,

    // start these browsers
    // available browser launchers: https://npmjs.org/browse/keyword/karma-launcher
    browsers: ["Chrome"],

    // Continuous Integration mode
    // if true, Karma captures browsers, runs the tests and exits
    singleRun: false,

    // Concurrency level
    // how many browser should be started simultaneous
    concurrency: Infinity,
  });
};
```

~~Karma の設定ファイルの`frameworks`にてテスティングフレームワークを変更できるので、mocha など他のものを利用することもできると思います。~~  
(2016-03-10 追記) Angular2 内部で Jasmine の DefinitelyTyped を参照しているため、Jasmine を使った方が幸せになれる気がします。

`karma.shim.js`という見慣れないファイルについては後で説明します。

## モジュールロードシステムが独自から systemjs に変更となった

Angular2 で大きく変わった点の一つは、モジュールロードシステムが[systemjs](https://github.com/systemjs/systemjs)に変更された点です。

Angular1 はモジュール名の名前解決による独自のモジュールロードシステムを持っていました。
基本的には`<script>`タグでロードした外部スクリプトを、Angular 上でモジュールとして再ロードすることで利用していました。

Angular2 では systemjs の設定ファイルにて利用する外部スクリプトを定義して、systemjs を介してモジュールをロードするようになります。
これまではテストランナーでテスト用のファイル一式をロードすれば十分でしたが、間に systemjs が 1 枚存在する形になります。

そこで、`karma.shim.js`の登場です。

## karma.shim.js とは

`karma.shim.js`とは、テストを行う前に systemjs にてモジュールがロードされていることを保証するために、Karma と systemjs の初期化のタイミングを制御する役割をするものです。

`karma.shim.js`の処理を大きく分けると次の 3 ステップでテストを実行しています。

1. systemjs 内にアプリケーションの静的リソースをロード
1. テスト用のブラウザと接続
1. Spec をロード&テスト実行

[refs](https://github.com/mitsuruog/angular2-minimum-starter/blob/master/karma.shim.js)

## サンプル Spec を作成して実行してみる

最後に簡単な Spec を実装してみます。シンプルな`AppComponent`です。

**app.component.ts**

```ts
import {Component, OnInit} from 'angular2/core';

@Component({
  selector: 'my-app',
  template: `
    <h1>Angular2 Minimum Starter Kit</h1>
  `
})

export class AppComponent {}
```

Spec を書いてみます。

**app.component.spec.ts**

```ts
import { Component, provide } from "angular2/core";
import {
  it,
  inject,
  injectAsync,
  beforeEachProviders,
  TestComponentBuilder,
} from "angular2/testing";

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

describe("Test: AppComponent", () => {
  beforeEachProviders(() => [AppComponent]);

  it("AppComponentが存在すること", inject(
    [AppComponent],
    (testee: AppComponent) => {
      expect(testee).toBeDefined();
    }
  ));
});
```

テストを実行してみます。

```
karma start karma.conf.js
```

テストを実行すると結果が表示されます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/testing-angular2-1-run.png)

## まとめ

モジュールロードシステムが SystemJS に変更されたことで、少し面倒になりましたがこれで Angular1 と同様にユニットテストを行う準備ができるはず！！

### PR

こちらに初学者のための Minimum starter kit を作成しましたので、ぜひ利用してください。
(もちろんすぐテストできます！！)

[mitsuruog/angular2-minimum-starter: Minimum starter kit for angular2](https://github.com/mitsuruog/angular2-minimum-starter)

### 参考

- [juliemr/ng2-test-seed: Work in Progress - Example, cloneable setup for an Angular2 application with tests.](https://github.com/juliemr/ng2-test-seed)
- [ghpabs/angular2-seed-project: Angular 2 Seed Project – Gulp, TypeScript, Typings, Karma, Protractor, Sass and more.](https://github.com/ghpabs/angular2-seed-project)

Angular2 Unit Testing - 準備編

SPA を構築する場合、Component をまたがったデータの共有をどのように実現するかが重要になってきます。  
Angular1 の場合は、SharedService を利用するケースが多かったです。  
そこで Angular2 でも試してみようとしたところ、少し勝手が違ったので自分用メモを残しておきます。



## 結論

- Angular2 では基本的に`@Injectable()`の DI は新規のインスタンスを生成します。
- Singleton で扱いたい場合は、`bootstrap(.., [ServiceA,ServiceB])`で DI すること。

## サンプル

Angular2 の公式ページでよく利用される HeroList を例に説明します。

- 画面の component は一覧(HeroListComponent)と詳細(HeroDetailComponent)の 2 つ。
- Hero 一覧データは HeroService に格納され、各 component は HeroService を参照する。

簡単な図に示すとこのような構造をしていると仮定します。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/IMG_20160229_001319.png)

## 失敗パターン

すべてのサンプルはこちら  
[plnkr](http://plnkr.co/edit/R1q9vzDa1gHXHBUClu1s?p=preview)

失敗パターンでは、HeroDetailComponent にて Hero を削除しても消えません。  
これは HeroDetailComponent の`providers`で HeroService を DI した場合、新規でインスタンスを生成してしまうためです。
結果、HeroListComponent と HeroDetailComponent では、別の HeroService のインスタンスを参照していることになっています。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/IMG_20160229_001409.png)

HeroDetailComponent で`@Component`を DI している箇所を抜粋します。

**hero-detail.component.ts**

```ts
import {Component,  Input}  from 'angular2/core';
import {Hero, HeroService}   from './hero.service';

@Component({
  selector: 'hero-detail',
  template: `
  <span class="badge">{{hero.id}}</span> {{hero.name}}
  <button (click)="remove()">remove</button>
  `,
  providers:  [HeroService]  // <- ここ
})
export class HeroDetailComponent implements OnInit  {
  @Input() hero: Hero;
  constructor(private service:HeroService){ }
  remove() {
    this.service.remove(this.hero);
  }
}
```

## 成功パターン

すべてのサンプルはこちら  
[plnkr](http://plnkr.co/edit/iYFMhuldCBqay72eWjay?p=preview)

こちらは SharedService として動作しているパターンです。`bootstrap(.., [ServiceA,ServiceB])`で HeroService を指定することで Singleton として扱うことができます。  
HeroDetailComponent で Hero を削除した場合、HeroListComponent の一覧も消えます。

**main.ts**

```ts
import { bootstrap } from "angular2/platform/browser";

import { AppComponent } from "./app.component";
import { Hero, HeroService } from "./heroes/hero.service";

bootstrap(AppComponent, [HeroService]);
```

## まとめ

Angular1 っぽい SharedService の作り方でした。  
正直、Two-way-binding と SharedService を利用した、手続き型っぽいやり方が Angular2 で最良の方法がどうかはわかりません。  
Angular2 でのベストプラクティスについてはまだ手探りな感じがします。

とはいえ、Angular1 を慣れている方であれば、Angular2 でも Component 間のデータ共有は SharedService でできることが分かりました。

refs [Angular2 "Services" how to @inject one service into another (singletons) - Stack Overflow](http://stackoverflow.com/questions/33575456/angular2-services-how-to-inject-one-service-into-another-singletons)

Angular2でSharedServiceを作りたい

Angular2 学習のため、大量に素振りする必要がでてきたので、素振り用の StarterKit を作成してみました。

これから学習する方は、公式の[5 Min Quickstart](https://angular.io/docs/ts/latest/quickstart.html)を最初にやる場合が多いと思うので、ベースは 5 Min Quickstart を利用しています。
その上で、気軽に Heroku へ Deploy して公開できるよう工夫しました。

[mitsuruog/angular2-minimum-starter: Minimum starter kit for angular2](https://github.com/mitsuruog/angular2-minimum-starter)



## 5 Min Quickstart から Heroku Delpoy への道

公式の[5 Min Quickstart](https://angular.io/docs/ts/latest/quickstart.html)は、学習するための環境としては十分なのですが、
Heroku へ Deploy するために少し工夫が必要でしたので手順を紹介します。

### Heroku 上での devDependencies のインストール

Heroku は Deploy する前、`package.json`に書かれている`dependencies`の内容をインストールしますが、通常は`devDependencies`をインストールしません。

そのため、Heroku 上の`NPM_CONFIG_PRODUCTION`設定を無効にする必要があります。

```
heroku config:set NPM_CONFIG_PRODUCTION=false
```

この設定は Heroku の GUI 上の Settings のタブからでも設定できます。

### Heroku 上での HTTP Server の導入

5 Min Quickstart には[johnpapa/lite-server](https://github.com/johnpapa/lite-server)という、
[Browsersync](https://www.browsersync.io/)をベースとした開発用の HTTP サーバーが含まれています。

しかし、lite-server 上で`Lightweight development only node server`と謳われているため、別途 HTTP サーバーを導入します。
今回は[indexzero/http-server](https://github.com/indexzero/http-server)を利用しました。

まず、`package.json`の`devDependencies`に追加します。

```
npm install http-server -D
```

次に、Heroku 上でアプリを開始する際に実行するコマンドを`package.json`に追加しておきます。

**package.json**

```diff
-    "start": "concurrent \"npm run tsc:w\" \"npm run lite\" "
+    "start": "concurrent \"npm run tsc:w\" \"npm run lite\" ",
+    "start-heroku": "concurrent \"npm run tsc\" \"npm run http-server\" "
```

最後に、Heroku がアプリを開始する際のコマンドを変更するため`Procfile`を作成し、先ほどのコマンドを設定します。  
(Node.js アプリの場合、Heroku はデフォルトで`npm run start`を実行するようになっています。)

**Procfile**

```
web: npm run start-heroku
```

こちらで、Angular2 のアプリを Heroku 上に Deploy できるはずです。

## まとめ

`gulp`や`grunt`などを利用するとローカルで build プロセスを実行することも可能ですが、素振り程度で依存するもどうかと思い簡単なものを作成してみました。

Angular2 学習のため、大量に素振りする必要がある人にはちょうどいいと思います。

Angular2を最速でHerokuにDeployするMinimum Starter Kitを作成してみた

Angular2 の ComponentRouter を使った場合に発生する`Use "..." on the parent's route path.`エラーの対処法です。  
完全に小ネタ。



Nest した Routing の場合、親の`@RouteConfig`の path に`...`を付ける必要がある。

```js
// parent
@RouteConfig([
  {path: '/', component: HomeComponent, as: 'Home'},
  {path: '/list/...', component: ListComponent, as: 'List'}
])

// child
@RouteConfig([
  { path: '/:id', component: ListItem, as: 'ListItem' }
])
```

参考）

angular2 - Use RouterLink from a nested component - Stack Overflow  
http://stackoverflow.com/questions/34363176/use-routerlink-from-a-nested-component

Tag: angular2