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

この記事では、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での次のセッションをおすすめします。

• Deep Dive into the Angular Compiler | Alex Rickabaugh
• How Angular works | Kara Erickson
• How we make Angular fast | Miško Hevery
• The secrets behind Angular’s lightning speed | Max Koretskyi