IVYコンパイラーで、エントリーコンポーネントAPIが必要なくなった理由を誰かが明確に説明できますか？言い換えると、Angularが突然コンポーネントを動的に作成する前にヘッドアップを必要としないように、内部で何が変更されたか
IVYコンパイラーで、エントリーコンポーネントAPIが必要なくなった理由を誰かが明確に説明できますか？言い換えると、Angularが突然コンポーネントを動的に作成する前にヘッドアップを必要としないように、内部で何が変更されたか
回答:
Ivyが登場する前は、ViewEngineコンパイラーはNgModule構成とhtmlテンプレートに基づいてプログラム全体の分析を実行し、このグローバル推移情報に基づいてモジュールとコンポーネントのファクトリーを作成していました。
これは、テンプレートで参照していないentryComponentsコンポーネントがあり、NgModuleの配列に追加していない場合、このコンポーネントはコンパイルされず、Angularが認識していないため動的にレンダリングできないことを意味しますこのコンポーネントのファクトリを取得する場所。
追加すると、コンパイラーは専用ファクトリーを生成し、このファクトリーを内部HashMapに追加して、を介して解決できるようにしComponentFactoryResolverます。
Ivyは完全に新しいngtscコンパイラを導入しました。このメンタルモデルでは、デコレータはコンパイラです。
つまり、ngtscの全体的なアーキテクチャは、コンポーネント、パイプ、ngModuleなどのTypeScriptトランスフォーマーのセットです。
これらの変圧器のような静的関数を発するAppComponent.ɵfac、AppComponent.ɵcmp代わりに元のコンポーネント/パイプ/ ngModuleが配置されている同じファイルにtranspiledそのコードが存在を意味します。したがって、同じ場所にファクトリ（Angularコンポーネント/パイプ/モジュールのインスタンス化に必要なすべてのコード）があり、それらの静的プロパティから簡単にアクセスできます。
簡単に言うと、TypeScriptコンパイルに@Componentデコレータ付きのクラスを持つファイルが含まれている場合、ngtscコンパイラは同じファイル内でこのクラスのファクトリを生成します。
そのコンポーネントを任意のファイルにインポートすると、Angularは静的プロパティを介してそのファクトリーを簡単に発見できると推測できます。
以下も参照してください。