スタンドアロンコンポーネントAngularための包括的なガイド

このクイックガイドでは、スタンドアロンAngularコンポーネントについて見ていきます。これにより、コンポーネントにまつわる興奮、仕組み、作成方法をより深く理解することができます。続きを読む。

Desislava Dincheva Last Updated Feb 18, 2025 8min read

開発プロセスの変更と強化に関して、あらゆる手段を講じるフレームワークが1つあるとすれば、それはAngularです。最新のAngular 16.0.0 リリースでは、ツール、サーバーサイドレンダリング、リアクティブなどに大きな進歩が見られました。そして私にとって、スタンドアロンAPIの導入はAngular開発者コミュニティに多くの利点をもたらす最新バージョンの最大の改善点の1つです。特に、Schematics for Standalone Componentsという新機能は、再利用可能なUI要素やライブラリを構築する能力を刷新すると同時に、定型的なモジュールを排除しているようです。

そして、それはゲームを大きく変えているのではないでしょうか?

しかし、スタンドアロンAngularコンポーネント (SAC) を深く掘り下げて、それらを取り巻くすべての興奮、それらがどのように正確に機能するか、それらを作成する方法、スタンドアロンコンポーネントの概念が最初に提示されたAngular 14 以降に何が変わったかなどをより深く理解しましょう。

Angularスタンドアロンコンポーネントとは何ですか、それともこれはNgModulesに別れを告げるものですか?

それらを定義するための最短の方法は、スタンドアロンコンポーネントを使用すると、モジュールを使用せずにAngularアプリケーションを構築できることです。特定のモジュールに縛られていないため、アプリケーションのどの部分でも使用できます。これは、スタンドアロンクラスをNgModuleで宣言する必要がないため、定型コードが少なくなることを意味します。

基本的に、スタンドアロンコンポーネントは必須ではありません。はい、推奨されますが、必須ではありません。ただし、Angularは、少なくとも新しく作成するコンポーネントに対しては、常にスタンドアロンコンポーネントを使用することをお勧めします。彼らは単によりツリーシェイクしやすく、ボイラーが少ないです。スタンドアロンのコンポーネントとモジュールを混在させることができます。少なくとも将来的には、モジュールよりもスタンドアロンのコンポーネントを使用できることに同意しますが、コンポーネントの残りの部分をモジュール化したままにしておくことにした場合、それは悪い決定ではありません。

Angular 14 では、スタンドアロンコンポーネントのアイデアがスタンドアロン API とともに導入されました (当時は開発者向けプレビューでした)。これらは、どのモジュールにも属さず、他のコンポーネント内にネストされることなく独立して使用できるコンポーネントのタイプを指していました。対照的に、それより前にコンポーネントを作成したい場合は、通常、モジュールの宣言配列内で渡す必要があります。

その後、コンセプトが変わり始め、開発プロセスは徐々に進化していきました。

たとえば、公式のAngularドキュメントでは、「スタンドアロンのコンポーネント、ディレクティブ、およびパイプは、NgModuleの必要性を減らすことにより、オーサリングエクスペリエンスを合理化することを目的としています」と規定されています。既存のアプリケーションは、破壊的変更なしに、新しいスタンドアロンスタイルをオプションおよび段階的に採用できます。」

言い換えれば、ここには単純化があります。

Angular 16では、スタンドアロンコンポーネントの回路図機能と、自己完結型、モジュール式、再利用可能に設計されたスタンドアロンコンポーネントが正式に利用可能になりました。しかし、なぜAngularでスタンドアロンコンポーネントを使用するのでしょうか?NgModuleの使用に完全に取って代わるわけではありませんが、モジュール式で再利用可能なコードを作成する新しい方法を利用することができます。その過程で、Angularアプリの保守性とテスト容易性を向上させ、プロジェクト構造をそのまま維持することさえ実現しました。

これはとても素晴らしい選択肢です!

しかし、繰り返しになりますが、AngularスタンドアロンコンポーネントはNgModuleの代替品ではなく、代替品です。

Angularスタンドアロンコンポーネントには他にどのような利点がありますか?

Angularでスタンドアロンコンポーネントを使用する理由は、他にもいくつかあります。

これらは、クラスとそれに伴う他のすべての過剰を効果的に排除できる軽量ソリューションです。
以前持っていたはるかに重いクラスベースのAPIと比較して、より機能的なAPIを採用する能力。
これで、NgModuleを使用せずにコンポーネントを直接遅延ロードできます。
これには、機能をカプセル化し、他のコンポーネントで潜在的なバグを引き起こすことなく、アプリ全体でコードの再利用性を促進する機能が付属しています。
AppModule は、コンポーネントを使用してアプリケーションをブートストラップできるため、もう必要ありません。
スタンドアロンのAngularコンポーネントでのルーティングは、よりツリーシェイク可能になったため、ルーティングされたコンポーネントまたはルート設定を直接指すことができます。
他のスタンドアロンコンポーネント、ディレクティブ、パイプ、および既存のNgModuleも簡単にインポートできます。
各コンポーネントには独自のファイル(テンプレート、スタイル、TypeScriptコード)があるため、コード構造が大幅に向上します。
再利用性を念頭に置いてコンポーネントを設計し、新しい機能を追加したり、既存の機能を拡張したりするのも簡単です。
単体テストは、Angularスタンドアロンコンポーネントごとに特別に記述できます。

Angularでスタンドアロンコンポーネントを作成する方法は?

Creating them

最初のスタンドアロンコンポーネントの作成は非常に簡単で、 –-standalone フラグを使用して行われます。ただし、最初に、Angular 16 を使用していることを確認してください。

2. Using them

スタンドアロンコンポーネントは、次の 2 つの方法で使用できます。

別のスタンドアロンコンポーネントでは、同じスタンドアロンコンポーネントのimportsプロパティに渡すだけです。
または、モジュール内で imports 配列に渡します。

スタンドアロンコンポーネントとIgnite UI for Angularの使用

Angular 16 およびIgnite UI for Angular 16.0 以降では、スタンドアロンコンポーネントに必要なインポートを imports プロパティに簡単に追加できるようになりました。次の例では、IGX_GRID_DIRECTIVES を使用して、グリッド関連のすべてのコンポーネントとディレクティブをインポートできます。ここでは、Ignite UIを使用してAngularスタンドアロンコンポーネントを作成して使用する方法を示します。

import {IGX_GRID_DIRECTIVES} from 'igniteui-angular';

@Component({  
   selector: 'app-grid-sample',
   styleUrls: ['grid.sample.scss'],
   templateUrl: 'grid.sample.html',
   standalone: true,
   imports: [IGX_GRID_DIRECTIVES, AsyncPipe] 
})

また、スタンドアロンコンポーネントで使用されるすべてのコンポーネントを個別にインポートすることもできます。IgxGridComponent と IgxColumnComponent の 2 つだけが別のコンポーネントで使用される場合の例を次に示します。

import {IgxGridComponent, IgxColumnComponent} from 'igniteui-angular'; 

@Component({  
   selector: 'app-grid-sample',
   styleUrls: ['grid.sample.scss'],
   templateUrl: 'grid.sample.html',
   standalone: true,
   imports: [IgxGridComponent, IgxColumnComponent, AsyncPipe] 
})

これで、すべてのIgnite UI for Angularコンポーネントがスタンドアロンコンポーネントとしてエクスポートされるようになりました。ライブラリは、下位互換性のために保持されているNgModuleを引き続きエクスポートしますが、Ignite UI for Angularコンポーネントは宣言されなくなりました。

代わりに、スタンドアロンコンポーネントをインポートおよびエクスポートするだけです。スタンドアロンコンポーネントはまだプレビュー段階にあることに注意することが重要です。一部のユーティリティディレクティブのエクスポートは将来変更される可能性があり、初期リリースのドキュメントに見つからない可能性があるため、機能のプレビュー状態になります。

スタンドアロンコンポーネントAngularためのベストプラクティスにはどのようなものがありますか?

Angularスタンドアロンコンポーネントを使用する場合は、いくつかのベストプラクティスに従って、クリーンで保守可能で再利用可能なコードと、次のレベルのプロジェクトを確保できます。

プロジェクトとコードのサイズを考慮する

最初のステップとして、プロジェクトの規模とコードの構成方法を検討します。すべてのコンポーネントをスタンドアロンに切り替えるだけで、通常のコンポーネントからスタンドアロンコンポーネントへの移行に関連する重大な変更はありません。ただし、アプリケーションにいくつかの大きなバグが導入されることは保証できます。ただし、すべてのコードをスタンドアロンコンポーネントに移行したくない場合があります。モジュール内のコンポーネントをバンドルし、その一部だけをエクスポートすることは、完全に細かいパターンです。これをスタンドアロンコンポーネントにどのように変換しますか?ngModuleの代わりに、バレルファイルを使用してAPIを設定し、プライベートコンポーネントをリンティングルールで保護する必要があります。この場合、スタンドアロンのコンポーネントが必ずしもプロジェクトの管理を容易にするわけではありません。

したがって、プロジェクトの規模が中規模から大規模の場合、この移行をかなりゆっくりと開始し、すべての SCAM (Single Component Angular Module) のみを移行することをお勧めします。SCAM では、NgModule は 1 つのコンポーネントのみを宣言します。これらはすでに分離されているため、それ以降はスタンドアロンコンポーネントの作成方法と操作方法に慣れることができます。

パイプとディレクティブの移行

別の良い方法は、すべてのパイプとディレクティブをスタンドアロンコンポーネントに移行することです。これにより、一部のモジュールを簡略化および削減できます。

コードを調整し、継続的に改善する

その後、自分自身とチームが定期的なコードリファクタリング中にコードベースを調整し、継続的に改善する時間を確保してください。なぜなら、エンタープライズ規模のプロジェクトでは、スタンドアロンコンポーネントへの移行は大規模な作業になるからです。これにより、リグレッションが発生しないようにしながら、すべての変更が同僚によって十分にテストされ、レビューされることを確認できます。

結論として...

スタンドアロンコンポーネントが私にとって多くの定型文を削除するという議論は、部分的にしか真実ではありません。モジュールを作成する必要はなくなりました。代わりに、ほとんどすべてのコンポーネントがAngular期待どおりに動作するためには、少なくともCommomModuleをインポートする必要があります。より複雑なケースでは、他のモジュールやコンポーネントのかなり長いリストもインポートする必要があります。場合によっては、これにより非常に長い import ステートメントが発生し、ファイルを開くときに、コンポーネント自体のコードを実際に見るためにページ全体をスクロールする必要があります。

この問題に対する簡単な答えはありません。CommonModuleを切り取って、必要なものだけをインポートするようにすることが提案されていますが、これによりインポートのリストが長くなりやすくなります。別の方法として、*ngIf ディレクティブなどの特定の機能がデフォルトでインポートされるという方法もあります。現在、Angularチームによるこの方向での具体的な計画はありません。

したがって、両方の概念をしばらくの間プロジェクトのコードベースで一緒に存在させ、プロジェクトがどのように進化し続けるか、そして何が最適に機能するかを確認することは悪いことではありません。

Angular