DEV Community: Angular Japan User Group

Angular: Lightweight Injection Tokenという新しいテクニック

Suguru Inatomi — Wed, 29 Jul 2020 04:57:17 +0000

最近Angularチームが発見し、Angularライブラリの実装におけるパターンとして普及させようとしているのが、 Lightweight Injection Token というテクニックだ。これはこれまで不可能だった コンポーネント(ディレクティブ)のTree-Shaking を可能にする。本稿ではこの新しいテクニックの概要、そして生まれた経緯や深く知るための参考リンクをまとめる。

なお、Lightweight Injection Tokenについては公式ドキュメントでも解説される予定であるため、そちらを参照すればいい部分は省略する。

Angular - Optimizing client app size with lightweight injection tokens

Lightweight Injection Tokenの概要

ひとことでいえば、「オプショナルな機能に関連するInjection Tokenとして代替の軽量トークンを使う」ということである。AngularのDIを深く理解していればこれだけでピンと来るかもしれないが、具体例から概要をつかもう。

あるAngularライブラリが、次のような使い方ができる <lib-card> コンポーネントを提供している。

<lib-card>
  Hello World!
</lib-card>

このコンポーネントは、Contentとして <lib-card-header> コンポーネントを配置すると、カードのヘッダーとして取り扱う オプショナル な機能があることをイメージしよう。

<lib-card>
  <lib-card-header>Greeting Card</lib-card-header>
  Hello World!
</lib-card>

ライブラリ側はこのような使い方ができるコンポーネントを実装するとおおよそ次のようになるだろう。 @ContentChild() を使って CardHeaderComponent の参照を得る。ただしこのヘッダーを置くかどうかはユーザー次第なので、 CardHeaderComponent|null という形でnullを許容することになる。

@Component({
  selector: 'lib-card-header',
  ...,
})
class CardHeaderComponent {}

@Component({
  selector: 'lib-card',
  ...,
})
class CardComponent {
  @ContentChild(CardHeaderComponent)
  header: CardHeaderComponent|null = null;
}

ここで問題になるのが、 CardComponent から CardHeaderComponent への参照の持ち方である。 @ContentChild(CardHeaderComponent) と header: CardHeaderComponent|null の2箇所で参照を持っているが、この2つは性質が異なる。

後者の header: CardHeaderComponent|null は、型としての参照である。この参照はTypeScriptのコンパイル時型チェックにのみ用いられ、コンパイル後のJavaScriptには残らないため問題にならない。

問題は前者の @ContentChild(CardHeaderComponent) だ。これは値としての参照であり、 CardHeaderComponent というクラスオブジェクトそのものを参照している。それが直接 @ContentChild() デコレーターに渡されているのだから、 ユーザーがヘッダーを使おうが使わまいが、この参照は実行時に残る 。

@ViewChild() や @ContentChild() の走査条件として使われるコンポーネント/ディレクティブのクラス参照はどうしてもTree-Shakingできず、これがAngularライブラリを利用したときの バンドルサイズの肥大化の原因 となる。

これを解決するためのアプローチが、Lightweight Injection Tokenだ。上記の例で @ContentChild() デコレーターに渡していたクラスを、次のように軽量なオブジェクトを利用したInjection Tokenに置き換える。

// Lightweight Injection Token
abstract class CardHeaderToken {}

@Component({
  selector: 'lib-card-header',
  providers: [
    {provide: CardHeaderToken, useExisting: CardHeaderComponent}
  ]
  ...,
})
class CardHeaderComponent extends CardHeaderToken {}

@Component({
  selector: 'lib-card',
  ...,
})
class CardComponent {
  @ContentChild(CardHeaderToken) header: CardHeaderToken|null = null;
}

まず CardHeaderToken 抽象クラスを作成し、 CardHeaderComponent をその具象クラスとする。そしてコンポーネントプロバイダーで CardHeaderToken に対して自身のクラスオブジェクトを提供する。 CardComponent ではトークンを @ContentChild()デコレーターの走査条件とする。

これにより、 CardComponent から直接の CardHeaderComponent への参照はなくなり、ライブラリのユーザーが <lib-card-header> コンポーネントを呼び出したときだけ CardHeaderToken に対して CardHeaderComponent クラスのインスタンスが提供されることになる。

@ContentChild() や @ViewChild() の引数としてDIトークンを渡せるようになるのがバージョン 10.1.0からなので、このアプローチが取れるのは バージョン 10.1.0以降 になる（ as any で突破する手法はあるが）。

feat(core): support injection token as predicate in queries (#37506) · angular/angular@97dc85b

なぜ今なのか、これまでの経緯

この問題は昔からずっと存在したが、実はバージョン8まではそれほど重大な問題ではなかった。なぜかというとバージョン8以前、つまりIvy以前 (ViewEngine, VE) はAOTコンパイルによってテンプレートコンパイルされた結果の生成コードが、もとのコンポーネントとは別のクラス実体をもっていたからだ。

ViewEngineでは CardComponent クラスのデコレーターとそのメタデータをもとに CardComponentNgFactory クラスが生成される。そして、JavaScriptとしてコードサイズが大きいのはほとんどの場合NgFactory側である。

つまり上記の例でいえば、たとえ CardComponentNgFactory クラスが CardHeaderComponent への参照を持っていたとしても、CardHeaderComponent そのものが大きくないために問題にならなかったのだ。サイズが大きいのは CardHeaderComponenNgFactory のほうで、NgFactoryはテンプレート中で <lib-card-header> を使わない限り参照されないため、不完全ではあるがTree-ShakingできていたのがViewEngine方式だった。

バージョン9からデフォルトになったIvy方式のAOTコンパイルは、生成コードを もとのクラスの静的フィールドとして合成する 。よって AOTコンパイルすると CardHeaderComponent そのもののサイズが大きくなり、 CardComponent に巻き込まれて一緒にバンドルされるサイズが顕著に大きくなる。いままで行なわれていた生成コードのTree-ShakingがIvyによりなくなってしまった。

つまり、Lightweight Injection TokenはViewEngine時代には顕在化していなかったがIvyによってクリティカルになった問題を解決するために編み出された、 Ivy時代のAngualrライブラリ実装パターン である。

もっともポピュラーなAngularのコンポーネントライブラリであるAngular Materialではバージョン9リリース時からバンドルサイズの増加が報告されており、その解消の過程でAngularチームが辿り着いた答えである。現在Angular ComponentsチームはAngular Materialの各コンポーネントをLightweight Injection Tokenパターンに置き換える作業を進めている。

Increased initial main.js bundle size in v9 - mainly due to @angular/material packages · Issue #19610 · angular/components

Use light-weight injection pattern for optimized tree-shaking/bundle size · Issue #19576 · angular/components

コンポーネント以外のLightweight Injection Token

ところで、 @ContentChild() などの走査条件でなくとも、通常のDIの中でもオプショナルなものについてはLightweight Injection Tokenパターンを使うべきである。 @Optional() を使っていてもそのトークンの参照は残るためTree-Shakingはできない。コンストラクタDIでは型注釈部分にしか参照がないためコンパイルすれば消えそうに見えるが、コンストラクタ引数の型注釈はAOTコンパイル時に自動的に @Inject() デコレーターに変換されるため、実体参照をもつのである。つまりこれも @ContentChild() と全く同じ構造であり、同じ問題をもちうる。ライブラリ作者であればオプショナルなプロバイダーのトークンは可能な限り軽量にしておくべきだろう。

class MyComponent {
  constructor(@Optional() srv: OptionalService) {}
}

// Same
class MyComponent {
  constructor(@Optional() @Inject(OptionalService) srv: OptionalService) {}
}

ちなみにコンポーネントのLightweight Injection Tokenとして InjectionToken オブジェクトを使うこともできるはずだ。公式ドキュメントでは抽象クラスの例が紹介されているが、どちらが定着するかは今後のコミュニティでの受け入れられ方次第だろう。ただ、トークンの抽象クラスとコンポーネントクラスを継承関係にするとそのままコンポーネントのAPI定義として利用もできるため、おそらくは抽象クラスのほうが便利な場面は多そうだ。

const CardHeaderToken
  = new InjectionToken<CardHeaderComponent>("CardHeaderComponent");

https://angular.io/guide/dependency-injection-providers#non-class-dependencies

参考リンク

以下に参考リンクをまとめる。

Misko HeveryによるDesign Doc https://hackmd.io/@mhevery/SyqDjUlrU
公式ドキュメントへの追加PR https://github.com/angular/angular/pull/36144
Angular MaterialのIssue https://github.com/angular/components/issues/19576

Event Coalescing to improve performance

JiaLiPassion — Thu, 16 Jan 2020 01:18:04 +0000

Event Bubbling の性能の問題

下記のAngularアプリケーションでのHTMLテンプレートコードを見ましょう。

<div (click)="doSomething()">
  <button (click)="doAnotherThing()">Button</button>
</div>

Event Bubbling のため、DivのなかのButtonをクリックしたら、両方のEvent ListenerがTriggerされます。この２つのEvent Listenerが全部Change Detectionを実行します。実際はこのようなケースでChange Detectionを一回だけ実行したいです。特にこのようなケースがAngular MaterialとかUI ライブラリで結構普通のケースですので、性能改善したいです。

実行順番

まず上記のケースでEvent ListenerとChange Detectionの実行順番を見ましょう。

export class AppComponent {
  doSomething() { // event listener for parent div
    console.log('event listener for parent div');
  }
  doAnotherThing() { // event listener for inner button
    console.log('event listener for inner button');
  }
}

そして、Zone.jsがEvent ListenerをMonkey patchされましたので、下記のような感じのコードになりました。

function eventHandler(...) {
  try {
    realHandler(...); // doSomething あるいはdoAnotherThingのDelegate
  } finally {
    applicationRef.tick();
  }
}

そしたら、Buttonをクリックするとき、実行の順番が下記のようになりました。

event listener for inner button
applicationRef.tick
event listener for parent div
applicationRef.tick

実際ほしいのは

event listener for inner button
event listener for parent div
applicationRef.tick

です。

解決方法

Change Detectionを同期ではなく、非同期で実行することです。

isChangeDetectionScheduled = false;
function eventHandler(...) {
  try {
    realHandler(...); // doSomething あるいはdoAnotherThingのDelegate
  } finally {
    if (isChangeDetectionScheduled) {
      return;
    }
    isChangeDetectionScheduled = true;
    requestAnimationFrame(() => {
      isChangeDetectionScheduled = false;
      applicationRef.tick();
    }); 
  }
}

のような感じのコードでChange DetectionをrequestAnimationFrameのSchedulerで実行させ、そしてもしScheduleされたTaskがあったら、スキップして、なかったら、Scheduleするということです。

設定方法

bootstrapModuleのとき、かきのOptionを設定することができます。

platformBrowserDynamic().bootstrapModule(AppModule, {ngZoneEventCoalescing: true})

副作用

このオプションをTrueにしたら、もともと同期のChange Detectionが非同期になりました、普通のアプリケーションには影響がないですが、Google 内部でのEdge Caseで同期のChange Detectionが求めるテストケースがあるらしくて、それ以外が特に既存のアプリケーションには影響ないはずです。
この機能がすでに最新バージョンで使えますので、なにか問題が発見されたら、ぜひAngular RepoにIssueを提出ください。

以上です。

どうもありがとうございました！

なぜentryComponentsは非推奨になるのか

Suguru Inatomi — Mon, 04 Nov 2019 03:45:08 +0000

この記事では、Angular v9.0にて非推奨となる entryComponents 機能が、なぜ非推奨になるのかについてできるだけ簡単に解説します。

Angular - Deprecated APIs and Features

はじめに

解説を始める前に、重要な点をあらかじめ書き記しておきます。

もしIvyをオプトアウトする場合は、 entryComponents は引き続き必要です。決して削除しないでください。
いままで entryComponents 機能を使ったことがない方が新たになにか覚える必要はありません。興味がなければ過去のものとして無視してください。

`entryComponents` とは何なのか

v9.0 で非推奨となる entryComponents とは何だったのかということをまずは振り返りましょう。

entryComponents は多くの場合、 動的なコンポーネント を実現するために利用されます。動的なコンポーネントとは、AngularのテンプレートHTML内に登場せず、コードの実行によって生成されるコンポーネントです。テンプレートHTMLを静的に検査しても宣言が見つからないことから動的と呼ばれます。

Angular - 動的コンポーネントローダー

もっとも代表的なユースケースはダイアログやモーダルのようなケースです。コンポーネントクラスの処理が実行されることで動的にコンポーネントが表示されます。このようなコンポーネントはテンプレートHTML内に宣言されません。

たとえばAngular CDKのOverlay APIを使ってコンポーネントをオーバーレイ上に表示するには次のようなコードを書きます。

export class AppComponent {
    constructor(private overlay: Overlay) {}

    openModal() {
        const overlayRef = overlay.create();
        const modalPortal = new ComponentPortal(MyModalComponent);
        overlayRef.attach(modalPortal);
    }
}

このとき、動的に表示したい MyModalComponent は、それが宣言される NgModule の entryComponents 配列に追加される必要があります。

@NgModule({
    declarations: [AppComponent, MyModalComponent],
    entryComponents: [MyModalComponent],
})
export class AppModule {}

なぜ `entryComponents` が必要なのか

Angularに慣れている人にとっては、もはや当たり前のように「モーダルを実装するときは entryComponents 」というルーチンになってしまっているかもしれませんが、そもそもなぜこれが必要なのでしょうか。その理由は、Angular v8までのAoTテンプレートコンパイラと、そのテンプレートコンパイラが生成する実行コードに理由があります。

ここで以降の説明の簡単のため、v8以前のAoTコンパイラを ViewEngine (VE) コンパイラと呼びます。

コンポーネントの生成とComponentFactory

動的コンポーネントの生成には ComponentFactoryResolver というAPIを使います。このAPIはコンポーネントクラスから、そのコンポーネントに対してAoTコンパイラが生成した ComponentFactory オブジェクトを返すものです。

export class AppComponent {
  constructor(private cfr: ComponentFactoryResolver) {}

  ngOnInit() {
    const componentFactory = this.cfr.resolveComponentFactory(SomeComponent);
  }
}

先ほど紹介したCDKのOverlayやPortalの機能も、この ComponentFactoryResolver を利用しています。そして、 entryComponents に追加されたコンポーネントだけがこの resolveComponentFactory メソッドの引数に使えます。もし追加されていなければ次のようなエラーが表示されます。

つまり、 entryComponents とは、「あるコンポーネントのComponentFactoryを解決可能にする」ための機能であると言えます。ではなぜ entryComponents に追加されていないコンポーネントのComponentFactoryは解決できないのでしょうか。すべてのコンポーネントは等価ではないのでしょうか？

ViewEngineはTree-shakableなComponentFactoryを生成する

その答えは半分YESです。ViewEngineのAoTコンパイラは NgModule.declarations 配列に指定されたすべてのコンポーネントのComponentFactoryを生成しています。しかし、それが ComponentFactoryResolver から解決可能になっていないのです。

この様子は実際にAoTコンパイルの結果を見るとはっきりとわかります。Angular CLIのプロジェクトであれば、 ngc -p ./tsconfig.app.json とコマンドを実行すれば tsc-out ディレクトリにAoTコンパイル結果が出力されます。その中には、すべてのコンポーネントに対して ./some.component.ngfactory.js のような ComponentFactoryの生成コードを見ることができます。

これでViewEngineではどのコンポーネントにもComponentFactoryは存在していることがわかります。しかし、これらのComponentFactoryは どこからも参照されていません。つまりAngular CLI（の内部で使われているwebpack）のビルドでは、不要なコードとしてバンドルに含められないのです。これが、ComponentFactoryResolver によってComponentFactoryを解決できないコンポーネントがある理由です。バンドルサイズ削減のために、不要なコードを含めない仕組みになっているのです。

ComponentとComponentFactoryの分断

しかしこれはおかしい話です。ソースコード中で SomeComponent を参照しているのだからそのComponentFactoryは必要なコードとしてバンドルに含められるべきです。

ここがViewEngineの限界です。ViewEngineのAoTコンパイラはComponentFactoryの生成コードを元のコンポーネントクラスとは別のファイルに出力します。つまり、 some.component.ts に対して some.component.js と some.component.ngfactory.js を出力します。したがって、アプリケーションで SomeComponent への参照があったとしても、 SomeComponent のComponentFactoryには一切参照が届かないのです。

`entryComponents` は `ComponentFactoryResolver` をセットアップする

ここでようやく entryComponents の出番です。 NgModule の entryComponents に追加されたコンポーネントのComponentFactoryは、AoTコンパイラが特別に解釈して ComponentFactoryResolver で解決できるように参照を作ります。その様子は AoTコンパイル後の app.module.ngfactory.js で見ることができます。

AoTコンパイルの生成コードをはじめて見る方は驚くかもしれませんが、今回注目すべき点は2ヶ所。インポート文と ComponentFactoryResolver のプロバイダ宣言です。見ての通り、 AppModuleNgFactory から参照されているのは app.component.ngfactory だけです。そして、 ComponentFactoryResolver の近くにある配列には AppComponentNgFactory だけがセットされています。

それでは、 SomeComponent を entryComponents 配列に追加してもう一度AoTコンパイルしてみましょう。 app.module.ngfactory.js に変化があるはずです。

新たに some.component.ngfactory への参照が追加され、ComponentFactoryResolver の近くにある配列に SomeComponentNgFactory が追加されています。実はこの配列こそが ComponentFactoryResolverが解決できるコンポーネントのリストです。

つまり、entryComponents によって NgModule のコンパイル結果に影響を与えることで、動的に利用したいコンポーネントのComponentFactoryがTree-shakingされないように、ComponentFactoryResolver から解決可能な参照を保持することができるのです。

なぜ `entryComponents` が非推奨になるのか

ViewEngineにおいて entryComponents がなぜ必要だったかを簡単に説明しましたが、なぜv9からは非推奨となるのでしょうか。それはViewEngineに変わるAngularの新しい IvyコンパイラがViewEngineの抱える問題を根本から解決したからです。

Ivyは同一ファイルにコード生成する

IvyのAoTコンパイラは元のコンポーネントファイルと同じファイル、しかも同じクラスの静的フィールドとしてコード生成します。実際にAoTコンパイル結果を見てみましょう。v9では次のような生成コードになります。IvyではAoTコンパイルによって追加される独自のファイルは一切ありません。

some.component.js は次のようになっています。3行目にあるのは元の SomeComponent から @Component デコレーターが除去されたクラスです。そしてデコレーターの中に定義されていたセレクターやテンプレートなどのメタデータが、 9行目以降のAoTコンパイラによる生成コードに変換されています。

ここで重要なことは、 SomeComponent のAoTコンパイル後コードが、 SomeComponent クラスと密に結合していることです。これにより、 SomeComponent を参照すれば自動的に SomeComponent のコンポーネント生成に必要なすべての情報を解決できます。

つまり、 app.module.js で some.component.js をインポートしているだけで、 SomeComponent のComponentFactoryは解決可能になるのです。

これが、 Angular v9でIvyによって entryComponents が非推奨になる理由です。 entryComponents の代替となる新たな方法に変わるのではなく、そもそも根本的に動的コンポーネントと静的コンポーネントを区別する必要がなくなるのです。

Tree-shakingの問題は？

ここまで読んだ方はもしかすると entryComponents がなくなることで、ViewEngineと比べてバンドルサイズが増えるのではないかと疑っているかもしれません。確かに、コンポーネントの生成コードだけを考えると、ViewEngineと比べてTree-shaking可能な領域は減っています。しかしIvyではその他のいくつもの改善によってトータルではほとんどのユースケースでバンドルサイズが削減されます。

もっとも大きな改善は、Angularのテンプレート機能がTree-shakableになることです。詳細は割愛しますが、 [prop]="someValue" や (eventName)="onEvent($event)" など、すべてのテンプレートの機能が個別にTree-shakingされます。アプリケーションで一度も使わなかったテンプレート機能はバンドルに含まれません。

また、コンポーネントと生成コードが同一ファイルになることでクラス定義やimport/exportのオーバーヘッドもなくなり、より少ないコードだけを生成すればよくなりました。また、ViewEngineではコンポーネントが子コンポーネントになる場合とホストコンポーネントになる場合で別の生成関数を定義していましたが、Ivyではひとつの生成関数に統合されるので、これによっても生成コードのサイズは減っています。

トレードオフはありつつも、Ivyでは差分コンパイルのスピード、バンドルサイズの削減、内部アーキテクチャの単純化などの複合的な視点で、Ivyのアーキテクチャを選択しています。

動的コンポーネントを超えた遅延コンポーネントへ

IvyのAoTコンパイラは同一クラスの静的フィールドにComponentFactoryを生成すると説明しました。この変更による恩恵は entryComponents が不要になるだけではありません。ひとつのコンポーネントに関するコードが1ファイルに含まれることで、Dynamic Importによるコンポーネントの遅延読み込みも将来的には可能になります。

つまり、次のように動的な import() 文で取得した SomeComponent クラスでも ComponentFactoryResolver で解決できるということです。

export class AppComponent {
  constructor(private cfr: ComponentFactoryResolver) {}

  ngOnInit() {
    import('./some/some.component')
      .then(m => this.cfr.resolveComponentFactory(m.SomeComponent))
      .then(someCompFactory => {
        console.log(someCompFactory);
      });
  }
}

IvyではすべてのコンポーネントのComponentFactoryがバンドルに含められると説明しましたが、それはテンプレートHTMLやTypeScriptコードの中で 静的に 参照されている場合だけです。もし SomeComponent がこの Dynamic Import以外でまったく参照されていなければ、 Angular CLIは SomeComponent そのものを別バンドルに分離し、遅延読み込み可能にします。モーダル用のコンポーネントであれば、初期読込されるJavaScriptにはコンポーネントを含めず、モーダルを表示するイベントが発生したときに初めて遅延読み込みすればいいわけです。

このようにViewEngineからIvyにアーキテクチャ変更したことによって、いままでは覚えるしかなかった「Angularではできない」や「Angularではこのようにする」といった慣例的な制約がいくつも取り払われていきます。そして不要になった（陳腐化した）APIは非推奨となっていきます。

非推奨化は必ずしも代替APIへの置き換えを意味するわけではないということを覚えておきましょう。

まとめ

v8までのViewEngineでは entryComponents が無ければComponentFactoryの解決ができなかった
Ivyではすべてのコンポーネントが常にComponentFactoryを保持しているため、いつでもどのコンポーネントも動的に利用できるようになる
entryComponents の非推奨化は代替APIへの置き換えではなく、そもそも動的コンポーネントと静的コンポーネントの区別が不要になったということである

Ivyについての詳しい話は、 AngularConnect 2019での次のセッションをおすすめします。