Angular 6+は、完全な依存関係注入ガイドです。 提供対プロバイダー：[]

Angular 6では、アプリケーションにサービスの依存関係を埋め込むための新しい改良された構文が導入されました（ provideIn ）。 Angular 7がすでにリリースされているという事実にもかかわらず、このトピックは依然として関連しています。 GitHub、Slack、およびStack Overflowのコメントには多くの混乱があるため、このトピックを詳しく見てみましょう。

この記事では、次のことを検討します。

1. 依存性注入
2. Angularに依存関係を注入する古い方法（ プロバイダー：[] ）;
3. 依存関係をAngularに提供する新しい方法（ providedIn： 'root' | SomeModule ）;
4. UseInシナリオprovideIn ;
5. アプリケーションで新しい構文を使用するための推奨事項。
6. まとめると。

依存性注入

DIについて既に考えている場合は、このセクションをスキップできます。

依存性注入 （ DI ）は、他のオブジェクトに依存するオブジェクトを作成する方法です。 依存性注入システムは、クラスをインスタンス化するときに依存オブジェクトを提供します。



- 角度付きドキュメント

正式な説明は適切ですが、依存性注入とは何かを詳しく見てみましょう。



すべてのコンポーネントとサービスはクラスです。 各クラスには特別なコンストラクターメソッドがあり、このメソッドを呼び出すと、このクラスのインスタンスオブジェクトが作成され、アプリケーションで使用されます。



サービスの1つに次のコードがあるとしましょう。

constructor(private http: HttpClient)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

依存性注入メカニズムを使用せずに作成する場合、 HttpClientを手動で追加する必要があります 。 次に、コードは次のようになります。

 const myService = new MyService(httpClient)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、この場合httpClientを取得する場所はどこですか？ また、作成する必要があります。

 const httpClient = new HttpClient(httpHandler)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、今ではhttpHandlerをどこで入手できますか？ など、必要なクラスがすべてインスタンス化されるまで。 ご覧のとおり、手動での作成は複雑で、プロセスでエラーが発生する可能性があります。



角度依存性注入メカニズムにより、これらすべてが自動的に行われます。 行う必要があるのは、コンポーネントコンストラクターで依存関係を指定することだけです。これらの依存関係は、手間をかけずに追加されます。

Angularに依存関係を注入する古い方法（プロバイダー：[]）

アプリケーションを実行するには、Angularはコンポーネントとサービスに実装する個々のオブジェクトについて知る必要があります。 Angular 6より前は、これを行う唯一の方法は、 プロバイダープロパティでサービスを指定することでした：[]デコレーター@NgModule 、 @Component 、および@Directive 。







プロバイダーの主な使用法は次の3つです。[] ：

1. すぐにロードされるモジュールの@NgModuleデコレーター（ eager ）。
2. 遅延ロードモジュールの@NgModuleデコレーター（ lazy ）。
3. デコレータ@Componentおよび@Directiveで 。

アプリケーションとともにダウンロードされるモジュール（Eager）

この場合、サービスはシングルトンとしてグローバルスコープに登録されます。 複数のモジュールのプロバイダー[]に含まれていても、シングルトンになります。 アプリケーションのルートレベルで登録されるサービスクラスの単一インスタンスが作成されます。

遅延ロードモジュール（遅延）

遅延モジュールに接続されたサービスのインスタンスは、初期化中に作成されます。 そのようなサービスをモジュールの熱心なコンポーネントに追加すると、エラーが発生します： MyServiceのプロバイダーがありません！ エラー

@コンポーネントおよび@ディレクティブでの実装

コンポーネントまたはディレクティブに実装されると、サービスの個別のインスタンスが作成され、このコンポーネントとすべての子で使用可能になります。 この状況では、サービスはシングルトンではなく、コンポーネントが使用されるたびにインスタンスが作成され、DOMからコンポーネントが削除されるとともに削除されます。







この場合、 RandomServiceはモジュールレベルで実装されておらず、シングルトンではありません。

ただし、 プロバイダーに登録されている： RandomComponentコンポーネントの[] 。 その結果、 <rand®m> </rand®m>を使用するたびに新しい乱数を取得します。

Angularに依存関係を注入する新しい方法（providedIn： 'root' | SomeModule）

Angular 6では、アプリケーションに依存関係を注入するための新しい「ツリーシェーカブルプロバイダー」ツールを取得しました。これは@Injectableデコレーターの提供されたプロパティを使用して使用できます。



ProvideInは、逆方向の依存関係の実装として想像できます。モジュールが接続先のサービスを記述する前に、サービスは接続先のモジュールを定義するようになりました。



サービスは、アプリケーションのルート （ 提供された： 'root' ）または任意のモジュール（ 提供された：SomeModule ）に埋め込むことができます。 givenIn ： 'root'はAppModuleでの実装の略語です。







新しい構文を使用する主なシナリオを分析しましょう。

1. アプリケーションのルートモジュールでの実装（ 提供された： 'root' ）;
2. すぐにロードされるモジュールでの実装（ eager ）;
3. 遅延ロード（ lazy ）を使用したモジュールでの実装。

アプリケーションのルートモジュールでの実装（providedIn： 'root'）

これは最も一般的な依存性注入オプションです。 この場合、サービスは実際に使用されている場合にのみバンドルアプリケーションに追加されます。 コンポーネントまたは他のサービスに組み込まれています。



新しいアプローチを使用すると、すべての記述されたサービスが使用されるモノリシックSPAアプリケーションに大きな違いはありませんが、provinedIn ： 'root'はライブラリを記述するときに役立ちます。



以前は、すべてのライブラリサービスをプロバイダーに追加する必要がありました：そのモジュールの[] 。 ライブラリをアプリケーションにインポートした後、1つしか使用されていなくても、すべてのサービスがバンドルに追加されました。 givenIn： 'root'の場合、ライブラリモジュールを接続する必要はありません。 目的のコンポーネントにサービスを組み込むだけです。

遅延読み込みモジュール（遅延）および提供先： 'root'

怠zyなモジュールで提供された「ルート」でサービスを実装するとどうなりますか？



技術的には、 「ルート」はAppModule の略ですが、Angularは、コンポーネントとサービスにのみ実装されている場合、モジュールの遅延バンドルにサービスを追加するのに十分なほどスマートです。 ただし、1つの問題があります（これは機能であると主張する人もいます）。 遅延モジュールでのみ使用されるサービスを後でメインモジュールに実装すると、サービスはメインバンドルに転送されます。 多くのモジュールとサービスを備えた大規模なアプリケーションでは、これにより依存関係の追跡の問題や予測できない動作が発生する可能性があります。



注意してください！ 複数のモジュールに単一のサービスを実装すると、理解するのが難しく、解明することができない隠れた依存関係が生じる可能性があります。



幸いなことに、これを防ぐ方法があります。以下でそれらを検討します。

すぐにロードされるモジュールへの依存性注入（熱心な）

原則として、このケースは意味をなさないため、代わりにgivenIn： 'root'を使用できます。 EagerModuleでサービスを接続すると、カプセル化に使用でき、モジュールを接続せずに実装を防ぐことができますが、ほとんどの場合、これは必要ありません。



本当にサービスの範囲を制限する必要がある場合は、古いプロバイダー：[]メソッドを使用する方が簡単です。これは、確かに循環依存関係につながらないからです。



可能な限り、すべての熱心なモジュールで提供された： 'root'を使用してみてください。

ご注意 遅延読み込みモジュールの利点（遅延）

Angularの主な機能の1つは、アプリケーションを簡単にフラグメントに分割できることであり、次の利点があります。

1. アプリケーションのメインバンドルのサイズが小さいため、アプリケーションの読み込みと起動が速くなります。
2. 遅延読み込みモジュールは十分に分離されており、対応するルートのloadChildrenプロパティで一度アプリケーションに接続されます。

遅延読み込みのおかげで、何百ものサービスとコンポーネントを備えたモジュール全体を簡単に削除したり、別のアプリケーションやライブラリに移動したりできます。



遅延モジュールを分離することのもう1つの利点は、モジュールでのミスがアプリケーションの他の部分に影響を与えないことです。 これで、リリース日でも静かに眠ることができます。

遅延ロードを伴うモジュールでの実装（providedIn：LazyModule）

特定のモジュールへの依存性注入により、アプリケーションの他の部分でサービスを使用できなくなります。 これにより、依存関係構造を維持できます。これは、乱雑な依存関係の注入が混乱を招く可能性がある大規模なアプリケーションに特に役立ちます。



興味深い事実：アプリケーションのメイン部分に遅延サービスを実装すると、アセンブリ（AOTでも）はエラーなしで失敗しますが、アプリケーションは「LazyServiceのプロバイダーがありません」というエラーでクラッシュします。

循環依存関係の問題

次のようにエラーを再現できます。

1. LazyModuleモジュールを作成します。
2. LazyServiceサービスを作成し、 providedIn ：LazyModuleを使用して接続します。
3. LazyComponentコンポーネントを作成し、それをLazyModuleに接続します。
4. LazyServiceをLazyComponentコンポーネントのコンストラクターに追加します。
5. 循環依存のエラーが発生します。

概略的には、service- > module-> component-> serviceのようになります。



LazyModuleに接続されるサブモジュールLazyServiceModuleを作成することにより、この問題を解決できます。 サービスをサブモジュールに接続します。





この場合、追加のモジュールを作成する必要がありますが、それほど労力を必要とせず、次の利点があります。

1. 他のアプリケーションモジュールへのサービスの導入を防ぎます。
2. コンポーネントまたはモジュールで使用される別のサービスに埋め込まれている場合にのみ、サービスがバンドルに追加されます。

コンポーネントへのサービスの埋め込み（providedIn：SomeComponent）

新しい構文を使用して@Componentまたは@Directiveにサービスを埋め込むことはできますか？



現時点ではありません！



各コンポーネントのサービスのインスタンスを作成するには、 プロバイダを使用する必要があります： @ omponentまたは@Directiveデコレータの [] 。

アプリケーションで新しい構文を使用するための推奨事項

図書館

givenIn：「root」はライブラリの作成に適しています。 これは、機能の直接使用される部分のみをメインアプリケーションに接続し、最終的なアセンブリのサイズを縮小するための非常に便利な方法です。



実用的な例の1つはngx-modelライブラリです。これは新しい構文を使用して書き直され、現在は@ angular-extensions / modelと呼ばれています。 新しい実装では、NgxModelModuleをアプリケーションに接続する必要はありません。ModelFactoryを必要なコンポーネントに埋め込むだけで十分です。 ここで実装の詳細を見つけることができます 。

遅延ダウンロードモジュール（遅延）

サービス用に別のgivenIn：LazyServicesModuleモジュールを使用し、それをLazyModuleにプラグインします。 このアプローチは、サービスをカプセル化し、他のモジュールに接続されないようにします。 これにより境界が設定され、スケーラブルなアーキテクチャの作成に役立ちます。



私の経験では、メインまたは追加モジュールへの偶発的な導入（providedIn： 'root'を使用）は混乱を招く可能性があり、最善の解決策ではありません！



givenIn ： 'root'も正しく機能しますが、 providedIn：LazyServideModuleを使用すると、他のモジュールに実装されたときに「プロバイダーが 見つかりません」というエラーが発生し、アーキテクチャを修正できます。 サービスをアプリケーションのメイン部分のより適切な場所に移動します。

プロバイダーを使用する必要がある場合：[]？

モジュールを構成する必要がある場合。 たとえば、サービスをSomeModule.forRoot（someConfig）にのみ接続します。







一方、この状況では、providedIn： 'root'を使用できます。 これにより、サービスがアプリケーションに1回だけ追加されることが保証されます。

結論

1. givenIn ： 'root'を使用して、アプリケーション全体で使用可能なシングルトンとしてサービスを登録します。
2. メインバンドルに含まれるモジュールには、 providedIn： 'root'を使用し、 提供されない場合：EagerlyImportedModuleを使用します。 例外的なケースでは、 プロバイダーを使用してください：[]カプセル化のため。
3. サービスでサブモジュールを作成して、スコープの提供を制限します。
4. LazyServiceModuleモジュールをLazyModuleにプラグインして、循環依存を防ぎます。
5. プロバイダーを使用します。 @ omponentおよび@Directiveデコレーターの []を使用して、新しいコンポーネントインスタンスごとに新しいサービスインスタンスを作成します。 サービスインスタンスは、すべての子コンポーネントでも使用できます。
6. 依存関係の範囲を常に制限して、アーキテクチャを改善し、依存関係の混乱を避けます。

参照資料

元の記事。

Angularはロシア語を話すコミュニティです。

ロシアでの角度のあるMeetup