GitBookアプリケーションコンフィグの管理この章の内容を理解するには以下の前提知識が必要です。値プロバイダーの宣言方法を、Tree-Shakableプロバイダーを使った手法に変更しました。アプリケーションコンフィグ多くのアプリケーションは実行時の振る舞いを柔軟に制御するために、定数や環境変数を使って設定を管理しています。APIサーバーのベースURLを開発環境とプロダクション環境で切り替えるためには、環境ごとに固有の文字列を使うように設計します。外部サービスのAPIキーや、アプリケーションのタイトルなども同様でしょう。ブラウザのUserAgentのように実行の初期段階で決定するものも、ある種の環境変数といえます。これらの値をコンポーネントやサービスに直接ハードコーディングしてしまうと、違う値を使ったテストは不可能になり、複数箇所への変更を一致させる努力が必要になります。これは単一責任の原則に反した、メンテナンス性の低い実装です。最初におこなうべきことはそれらの設定値をアプリケーションから隔離された場所に切り出すことです。それはたとえばJSONファイルであったり、定数管理用のTypeScriptファイルであったり、ビルド時の環境変数であったりと様々です。場合によっては設定値をバックエンドサーバーで管理し、起動時にHTTPリクエストして取得するかもしれません。メンテナンス性とスケーラビリティを両立したアプリケーションの設計には、実行前に決定されるいくつかの設定値によってアプリケーションの振る舞いを柔軟に変更できるようにすることが求められます。呼ぶことにしましょう。コンフィグへの参照アプリケーションコンフィグを扱う際のよくある失敗は、アプリケーションのいろんな場所から直接参照してしまうことです。Angularのアプリケーションで考えると、コンポーネントやサービスのそれぞれがアプリケーションコンフィグに直接依存する状態です。コンポーネントやサービス単体でのテストができず、設定値を変化させたテストを書くことができません。設定値が増えたり、名前や形式が変わったときに変更しなければならないモジュールも増えます。アプリケーション外とアプリケーション内が複雑に絡み合ったこの状態を解決するために、依存性の注入(DI)を活用しましょう。アプリケーションのブートストラップ時にコンフィグをDIに取り入れ、設定値がコンポーネントやサービスへ動的に注入されるようにします。その具体的な方法についてこれから学びます。省略であることは知っているでしょう。Provider)と呼ばれ、指定されたクラスのインスタンスを注入可能にするプロバイダーです。Provider)です。値プロバイダーを使った実装のパターンを見ていきましょう。コンフィグファイルまずはじめに、アプリケーションコンフィグの設定値を管理するファイルを用意します。ファイルに、アプリケーションの設定値を配置します。値プロバイダーを定義します。DIにおいて「何を注入するか」を識別する鍵のようなものです。プロバイダーとインジェクターは、実体を参照しない代わりにこのトークンを互いに参照します。クラスのインスタンスを使うのが一般的です。ファイルを作成し、次のようにトークンを作成します。コンストラクタに渡す文字列は何でもかまいませんが、トークンの変数名はアッパースネークケースとするのが慣例です。指定すると、このトークンで取得できるオブジェクトの型が文字列であることもAngularに伝えられます。トークンに値を提供するプロバイダーを作成します。設定と、その値の指定をします。フィールドではなく、トークンが自律的にプロバイダーを宣言します。NgModuleから静的に参照されないことがプロダクションビルドで不必要なコードを除去する際の助けとなります。ここまで全く結合していなかったコンフィグとアプリケーションが、DIを通じて関係を持ちました。DIを境界としてアプリケーションの中と外を分離し、アプリケーション内部からはコンフィグについてまったく関心を持たないようにできました。トークンに紐付いた値をコンストラクタ引数として注入します。メソッドで値を取得する方法もあります。メソッドの戻り値は正しく文字列型になります。}}抽象クラスを使ったAppConfigパターンここまでの内容が理解できたら次のステップに進みましょう。コンフィグの内容が増えてくると、それぞれに独立したプロバイダーとトークンを定義するのは面倒です。コンフィグは基本的に一箇所で管理されるものですから、変更のタイミングが同じだとすれば個別に管理される必要もありません。ファイルにリネームし、次のように変更します。宣言していることです。string;}プロバイダーのトークンに使えるのはJavaScriptとして実体のあるオブジェクトだけです。トークンになりません。抽象クラスはトランスパイル後にもクラスとして残るため、トークンとして使うことができます。この変更により、注入をおこなう側も影響を受けます。型をトークンとして注入できます。導入されたことで、これからコンフィグの中身が増えたとしても新たにプロバイダーやトークンを増やす必要はなくなりました。コンポーネントのコードも少なくなり、メンテナンス性の高いソースコードになりました。呼ぶことにしましょう。便利なパターンですが弱点もあります。管理する設定値が多くなると、注入する場所によってはそのほとんどが不要な値というケースが増えてきます。型ですから、テストの際にも本来は不要な設定値を渡す必要が生まれてしまいます。DIを利用した結果テストしにくくなってしまっては本末転倒です。大きくなりすぎたと感じたら、適切な粒度でコンフィグを分割すべきです。ようなものを作りましょう。抽象クラスを使ったAppConfigパターンAppConfigパターンの。