# はじめに
AngularではComponentインスタンスを作る方法がいくつかある。最もよく使うのはテンプレート上でComponentのselectorを書く方法、そして次に来るのが多分 [`NgComponentOutlet`](https://angular.jp/api/common/NgComponentOutlethttps://angular.jp/api/common/NgComponentOutlet) Directiveを使う方法、最後に [`ComponentFactory`](https://angular.jp/api/core/ComponentFactory) を使って [`ViewContainerRef`](https://angular.jp/api/core/ViewContainerRef) にTS上でインスタンスを挿入する方法ではないかと思う。

ここで生成したインスタンスに対して何かパラメータを渡すことを考える。この記事の本題は2番目に挙げた `NgComponentOutlet` を使う場合なのだが、一旦1番目と3番目の場合はどうだったかを最初に振り返っておく。

1番目のselectorを使う方法であれば単純に[プロパティバインディング](https://angular.jp/guide/property-binding)でパラメータ渡すことができる。

```html:selectorの場合
<app-some-component
  [params]="params"
></app-some-component>
```

ここで `SomeComponent` は以下のように `@Input` Decoratorで `params` を受け取るようなComponentである。

```typescript:some-component.ts
@Component({
  selector: 'app-some-component',
  templateUrl: './some.component.html',
  styleUrls: ['./some.component.scss'],
})
export class SomeComponent {
  @Input() params?: Record<string, unknown>;
}
```

そして、3番目の `ComponentFactory` を使う場合だと、SomeComponentには以下のようにパラメータを渡すことができる。本題ではないので詳細は省略する。

```typescript:ComponentFactoryの場合
// SomeComponentのComponentFactoryを作る
const componentFactory = this.componentFactoryResolver.resolveComponentFactory(
  SomeComponent
);
const componentRef = this.viewContainerRef.createComponent(componentFactory);
// componentのインスタンスを取得
const instance = componentRef.instance;
// インスタンスにデータをセット
instance.params = params;
```

そしていよいよ本題となる `NgComponentOutlet` で生成したインスタンスにパラメータを渡す場合である。

# NgComponentOutletでインスタンスを生成する

## NgComponentOutletとは
`NgComponentOutlet` はDirectiveである。動的なComponent生成を最も簡単にやろうとした場合に使うことになる。TSファイル側で変数にSomeComponent Classへの参照を持っておき、テンプレート上で以下のように記述すると、Directiveが勝手にインスタンスを生成してViewに反映してくれる。

```html:NgComponentOutletの使い方
<ng-container 
  *ngComponentOutlet="component"
></ng-container>
```

よって動的にComponentを切り替えたい場合には、`component` で参照するComponent Classを何かしらのロジックに従って差し替えてやれば良い。

## @Inputのプロパティに値を渡せない
上の例を見てわかる通り、SomeComponentはClassのままDirectiveに渡されており、そこで生成されたインスタンスにプロパティバインディングでパラメータを渡す手段がない。無理やりインスタンスへ参照を持って、`ComponentFactory` の場合と同様にパラメータをセットすることも可能かもしれないが、この記事ではDIを使ってこのComponentインスタンスにパラメータを渡す方法を考える。

## @InjectableなパラメータとそれをProvideするDirective

### @Injectableなパラメータ

```typescript:component-outlet-params.service.ts
import { Injectable } from '@angular/core';
import { BehaviorSubject } from 'rxjs';

@Injectable({
  providedIn: 'root',
})
export class ComponentOutletParams<T> {
  public readonly params$ = new BehaviorSubject<T | undefined>(undefined);

  public get params(): T | undefined {
    return this.params$.getValue();
  }

  public set params(params: T | undefined) {
    this.params$.next(params);
  }
}
```

パラメータを渡すためのService （Angularが公式で用意している `ActivatedRoute` などと同じようなイメージで捉えて貰えれば良い） を用意する。このServiceのメンバーにはObservableなパラメータと、パラメータを取得・更新するためのgetter/setterを定義している。

### パラメータをProvideするためのDirective
`NgComponentOutlet` で生成されるComponentインスタンスは一般的には1つではないだろうから、上記の `ComponentOutletParams` はシングルトンであってはいけない。基本的に`NgComponentOutlet` Directiveと一対一で対応するパラメータが存在することになる。よって、@Injectableで用意した `ComponentOutletParams` はこのDirectiveにおいてインスタンスを生成し、Directiveを付与したDOMのElement InjectorからProvideすることにする。

```typescript:component-outlet-params.directive.ts
@Directive({
  selector: '[appComponentOutletParams]',
  providers: [ComponentOutletParams],
})
export class ComponentOutletParamDirective<T> {
  constructor(private componentOutletParams: ComponentOutletParams<T>) {}

  @Input() set appComponentOutletParams(params: T | undefined) {
    this.componentOutletParams.params = params;
  }
}
```

プロパティバインディングするプロパティに対してsetterを定義しているため、Directiveに新しい値がセットされるたびに、`ComponentOutletParams` がもつObservableなパラメータには新しい値が配信される。

### Directiveを使ったパラメータの配信

```html:パラメータの配信
<div [appComponentOutletParams]="params">
  <ng-container *ngComponentOutlet="component"></ng-container>
</div>
```

> warn:Element Injectorの場所について
> 
> `<ng-container>` はDOMとして実体を持たないので、Element Injectorが存在しない。よって、`<ng-container>` を `<div>` でラップして、そこへパラメータセット用のDirectiveを付与している。このパラメータはこの `<div>` の子孫要素でInjectすることが可能となる。

### SomeComponentにおけるパラメータの受け取り
配信されたパラメータを受け取る側の `SomeComponent` の実装は以下のように変わる。プロパティの受け取りをプロパティバインディングからDIに変更している。

```typescript:some-component.ts
@Component({
  selector: 'app-some',
  templateUrl: './some.component.html',
  styleUrls: ['./some.component.scss'],
})
export class SomeComponent implements OnInit {
  constructor(
    private componentOutletParams: ComponentOutletParams<
      Record<string, unknown>
    >
  ) {}

  ngOnInit(): void {
    this.componentOutletParams.params$.subscribe((params) => {
      console.log(params);
    });
  }
}
```

# さいごに
プロジェクトで使う場合、パラメータの受け渡し方法がプロパティバインディングとDIで混在するのは若干微妙な感じもあるが、プロパティバインディングに拘るとなると冒頭の3番目に挙げた `ComponentFactory` のような方法になる。なので、それでごちゃごちゃと手続き的にやるのと比べればこの方法は比較的すっきりしていて悪くはないのではないかと思う。AngularはReactに比べて動的なコンポーネントを扱うのが苦手な印象があり、ある程度の妥協は仕方ないように思える。例えばReactであればこんなことは返す関数Componentを動的に変える関数を定義してやるだけである。テンプレートファーストなAngularに対して、JSファーストなReactの強みだと思う。

# Introduction
In Angular, there are several ways to create a Component instance. The most common is to write a Component selector on the template, and probably the next one is Using the [`NgComponentOutlet`](https://angular.io/api/common/NgComponentOutlet) directive method, and finally using the [`ComponentFactory`](https://angular.io/api/core/ComponentFactory) The last method is to use `ComponentFactory` to insert an instance on TS into [`ViewContainerRef`](https://angular.io/api/core/ViewContainerRef).

Now we think about passing some parameters to the created instance. The main topic of this article is the second case of using `NgComponentOutlet`, but let's look back at the first and third cases first.

If you use the first method of using selector, you can simply pass parameters using [property binding](https://angular.io/guide/property-binding).

```html:Case of selector
<app-some-component
  [params]="params"
></app-some-component>
```

Here, `SomeComponent` is a Component that accepts `params` with the `@Input` decorator as follows.

```typescript:some-component.ts
@Component({
  selector: 'app-some-component',
  templateUrl: './some.component.html',
  styleUrls: ['./some.component.scss'],
})
export class SomeComponent {
  @Input() params?: Record<string, unknown>;
}
```

And if you use the third one, `ComponentFactory`, you can pass parameters to SomeComponent as follows. Since this is not the main topic, I will omit the details.

```typescript:Case of ComponentFactory
// Creating a ComponentFactory for SomeComponent
const componentFactory = this.componentFactoryResolver.resolveComponentFactory(
  SomeComponent
);
const componentRef = this.viewContainerRef.createComponent(componentFactory);
// get instance of Component
const instance = componentRef.instance;
// Set a data in the instance
instance.params = params;
```

And now, the main topic, the case of passing parameters to the instance created by `NgComponentOutlet`.

# Creating an instance with NgComponentOutlet

## What is NgComponentOutlet?
`NgComponentOutlet` is a directive. If you have a reference to SomeComponent Class in a variable in the TS file, and write the following in the template, Directive will create an instance of the class by itself and reflect it in the View.

```html:Usage of NgComponentOutlet
<ng-container 
  *ngComponentOutlet="component"
></ng-container>
```

Therefore, if you want to switch Components dynamically, you should replace the Component Class referred to by `component` according to some logic.

## Cannot pass values to @Input properties.
As you can see in the example above, SomeComponent is passed to Directive as a Class, and there is no way to pass parameters to the instance created there by property binding. It may be possible to force a reference to the instance and set the parameters as in the case of `ComponentFactory`, but in this article, I would like to use DI to deliver the parameters to this Component instance.

## @Injectable parameters and the Directives that Provide them

### @Injectable parameters

```typescript:component-outlet-params.service.ts
import { Injectable } from '@angular/core';
import { BehaviorSubject } from 'rxjs';

@Injectable({
  providedIn: 'root',
})
export class ComponentOutletParams<T> {
  public readonly params$ = new BehaviorSubject<T | undefined>(undefined);

  public get params(): T | undefined {
    return this.params$.getValue();
  }

  public set params(params: T | undefined) {
    this.params$.next(params);
  }
}
```

Only the properties of the parameters are defined in Observable for the Service to pass the parameters. This should be arranged according to the requirements.

### Directives to Provide parameters.
The above `ComponentOutletParams` should not be a singleton, since there will generally be more than one Component instance created by `NgComponentOutlet`. Basically, there will be parameters that correspond one-to-one with the `NgComponentOutlet` Directive. Therefore, the `ComponentOutletParams` prepared by @Injectable should be instantiated in this directive and Provide from the Element Injector of the DOM to which the directive is given.

```typescript:component-outlet-params.directive.ts
@Directive({
  selector: '[appComponentOutletParams]',
  providers: [ComponentOutletParams],
})
export class ComponentOutletParamDirective<T> {
  constructor(private componentOutletParams: ComponentOutletParams<T>) {}

  @Input() set appComponentOutletParams(params: T | undefined) {
    this.componentOutletParams.params = params;
  }
}
```

Since setter is defined for properties that have property bindings, whenever a new value is set for a directive, the new value is delivered to the Observable parameters of `ComponentOutletParams`.

### Delivering parameters using a Directive

```html:Set Parameters
<div [appComponentOutletParams]="params">
  <ng-container *ngComponentOutlet="component"></ng-container>
</div>
```

> warn:Location of the Element Injector
> 
> Since `<ng-container>` does not have any entity as DOM, there is no Element Injector. Therefore, `<ng-container>` is wrapped with `<div>`, and a directive for the parameter set is given to it. This parameter can be Injected by the descendant elements of this `<div>`.

### Receiving parameters in SomeComponent
The implementation of `SomeComponent` that receives the delivered parameters changes as follows. Receiving properties is changed from property binding to DI.

```typescript:some-component.ts
@Component({
  selector: 'app-some',
  templateUrl: './some.component.html',
  styleUrls: ['./some.component.scss'],
})
export class SomeComponent implements OnInit {
  constructor(
    private componentOutletParams: ComponentOutletParams<
      Record<string, unknown>
    >
  ) {}

  ngOnInit(): void {
    this.componentOutletParams.params$.subscribe((params) => {
      console.log(params);
    });
  }
}
```

# Conclusion
If you use it in a project, it may be a little delicate to mix property binding and DI for parameter passing, but if you are concerned about property binding, you should use a method like the `ComponentFactory` mentioned in the first paragraph. I have the impression that Angular is not as good at handling dynamic components as React, so some degree of compromise seems unavoidable. For example, in React, this is just a matter of defining a function that dynamically changes the returning functional Component. I think this is the strength of React, which is JS-first compared to Angular, which is template-first.

Passing parameters to the Component generated by the NgComponentOutlet

NgComponentOutletで生成したComponentにパラメータを渡す

# はじめに
通常、Angularでは環境変数を `environment` フォルダ下の `environment.ts` からimportして利用する。環境によって環境変数を切り替えたい場合は、その環境に応じた `enviroment.dev.ts` や `enviroment.prod.ts` を定義して、`angular.json` で `fileReplacements` を定義することになる。しかし、ここで問題になるのが、この環境変数はAngularのビルド時にビルドファイルに埋め込まれてしまうため、あとから上書きすることができない、ということである。例えばステージング環境と本番環境で環境変数が違う場合、ステージング環境と本番環境ではAnuglarのビルドを別々に行う必要が生じ、完全に同一のビルドファイルをステージング環境から本番環境へ持っていくことができない。

この記事では主に上記のような状況を解決するため、環境変数を外から切り替えられるようにするための方法を紹介する。最初に結論をまとめておくと、以下の2点がポイントになる。

- `main.ts` において、動的な環境変数の取得を行い、`envrionment.ts` を書き換えて `'platform'` からProvideする。
- 環境変数はファイルから直接参照させず、DIさせる

# 実装について
## main.tsにおける環境変数の書き換え
`main.ts` というのはAngularプロジェクトの `scr` 下に必ず存在しているファイルで、Angularアプリの起動の起点となる場所である。通常、この `main.ts` が実行され、`AppModule` をbootstrapし、`AppModule` が `AppComponent` をbootstrapする、という流れでAngularアプリは起動する。

`main.ts` を開いてみると、実際に `main` 関数が定義され実行されていること、そして `main` 関数の中では `platformBrowserDynamic()` とそれに続いて `bootstrapModule()` という関数が実行されていることがわかる。後者の `bootstrapModule()` は先程述べた `AppModule` をbootstrapする関数であるが、前者の方、`platformBrowserDynamic()` で、実は `'platform'` から値をProvideすることができる。

一般的に、AngularのアプリではAppModuleのInjectorがroot Injectorで、その上はNull Injectorになるが、`platformBrowserDynamic()` で値をProvideすると、rootの一つ上の階層である `'platform'` においてInjectorを生成することができる。今回は`main.ts` で（AppModuleを起動する前に）環境変数の書き換え処理を実行し、ここで環境変数をProvideする。`'platform'` については[公式ドキュメント](https://angular.io/guide/hierarchical-dependency-injection#platform-injector)や以下の動画が参考になる。

<iframe width="560" height="315" src="https://www.youtube.com/embed/kf9sPXeuAok?start=928" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

コードは以下のようになる。

```typescript:main.ts
import { enableProdMode, InjectionToken } from '@angular/core';
import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';

import { AppModule } from './app/app.module';
import { environment } from './environments/environment';
import { overrideEnv } from './override-env';

if (environment.production) {
  enableProdMode();
}

/**
 * ここでは便宜上main.tsに記述しているが、InjectionTokenの定義は別ファイルにまとめたほうが良いと思う
 */
export const ENVIRONMENT = new InjectionToken<Record<string, unknown>>(
  'environment'
);

const main = async () => {
  overrideEnv(environment).then((dynamicEnv) => {
    platformBrowserDynamic([{ provide: ENVIRONMENT, useValue: dynamicEnv }])
      .bootstrapModule(AppModule)
      .catch((err) => console.error(err));
  });
};

main();
```

`main` 関数の中で最初に実行している `overrideEnv` は次のようなイメージで実装する。

```typescript:override-env.ts
export const overrideEnv = async <T>(env: T): Promise<T> => {
  try {
    const response = await fetch('https://sample.com/api/client-env');
    const dynamicEnv: T = await response.json();
    for (const key in dynamicEnv) {
      if (Object.prototype.hasOwnProperty.call(dynamicEnv, key)) {
        const targetProp = env[key];
        if (targetProp !== undefined) {
          env[key] = dynamicEnv[key];
        }
      }
    }
  } catch (e) {}
  return env;
};
```

この `overrideEnv()` は環境変数を引数に取り、サーバーから取得した環境変数で一致するプロパティがあればその値を書き換えた上で、書き換え後の環境変数を返している。関数内部の処理（動的な環境変数をどう取得するか、取得した環境変数をどうマージするか）については、個々のプロジェクト事情に応じて実装する必要がある。

## 環境変数の使用
以上で環境変数の用意はできた。この環境変数を使用するためには、先程定義した `InjectionToken` を使用してDIする。

```typescript:sample-component.ts
import { Component, Inject, OnInit } from '@angular/core';
import { ENVIRONMENT } from 'src/main';

@Component({
  selector: 'app-sample',
  templateUrl: './sample.component.html',
  styleUrls: ['./sample.component.scss'],
})
export class SampleComponent implements OnInit {
  constructor(@Inject(ENVIRONMENT) env: Record<string, unknown>) {}

  ngOnInit(): void {}

  handleClick(): void {
    console.log(this.env);
  }
}
```

当然ではあるが、環境変数は先程 `'platform'` に対してProvideした値を利用する必要があるので、`environment.ts` から直接環境変数を参照するのは禁止する必要がある。この記事の例ではそうなっていないが、`environment.ts` で、`environment` オブジェクト自体にTSDoc/JSDocで `@deprecated` を明記しておく、などの工夫はできると思う。

# さいごに
環境変数を動的に取り扱うために、`main.ts` で環境変数を上書きしてProvideする方法を紹介した。ひとつ余談として、今回は `main.ts` を利用してAngularアプリの起動前に処理を差し込んだが、Angularには `APP_INITIALIZER` という `InjectionToken` が用意されており、これを使うともう少しあと、`AppModule` が `AppComponent` をbootstrapする前に処理を差し込むことができる。こちらは基本的にServiceの初期化のための仕掛けのようで、値のProvideには適さない（恐らくできない）が、知っておくと役に立つことがある。今回想定した要件でも、環境変数を常にServiceから取得する、みたいな設計を取るのであれば、その環境変数Serviceを `APP_INITIALIZER` で初期化するという方法が考えられる。

# Overview
Normally, Angular uses environment variables by importing them from `environment.ts` under `environment` folder. If you want to switch environment variables depending on the environment, you should define `enviroment.dev.ts`, `enviroment.prod.ts`, and so on for that environment, and define `fileReplacements` in `angular.json`. However, the problem here is that these environment variables are embedded in the build file when Angular is built, so you can't overwrite them later. For example, if the environment variables are different between the staging and production environments, Anuglar must be built separately in the staging and production environments, and the same artifact cannot be brought from the staging environment to the production environment.

This article is mainly about how to solve the above situation so that environment variables can be switched from outside. To summarize the conclusion at first, the following two points are important.

- In `main.ts`, get the dynamic environment variables and rewrite `envrionment.ts` to Provide.
- Environment variables are not referenced directly from files, but are injected from DI continer.

# Implementation
## Rewriting environment variables in main.ts
`main.ts` is a file that always exists under `scr` of an Angular project, and it is the starting point for launching Angular applications. Normally, this `main.ts` is executed, bootstrapping `AppModule`, and then `AppModule` bootstraps `AppComponent`, and so on, to launch the Angular application.

If you open `main.ts`, you can see that the `main` function is actually defined and executed, and that within the `main` function, `platformBrowserDynamic()` and the function `bootstrapModule()` following it are executed. The latter, `bootstrapModule()`, is a function to bootstrap the `AppModule` I mentioned earlier, but the former, `platformBrowserDynamic()`, can actually Provide for `'platform'`.

In general, in Angular applications, the Injector of AppModule is the Root Injector, and above it is the Null Injector, but if you Provide the value with `platformBrowserDynamic()`, you can actually Provide to `'platform'`, which is one level above root. This time, we will rewrite the environment variables in `main.ts` (before starting AppModule), and then Provide the environment variables here. For more information about `'platform'`, please refer to the [official document](https://angular.io/guide/hierarchical-dependency-injection#platform-injector) or the following video.

<iframe width="560" height="315" src="https://www.youtube.com/embed/kf9sPXeuAok?start=928" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

The code is as follows.

```typescript:main.ts
import { enableProdMode, InjectionToken } from '@angular/core';
import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';

import { AppModule } from './app/app.module';
import { environment } from './environments/environment';
import { overrideEnv } from './override-env';

if (environment.production) {
  enableProdMode();
}

/**
 * The definition of InjectionToken is written in main.ts for convenience, but I think it is better to put it in a separate file.
 */
export const ENVIRONMENT = new InjectionToken<Record<string, unknown>>(
  'environment'
);

const main = async () => {
  overrideEnv(environment).then((dynamicEnv) => {
    platformBrowserDynamic([{ provide: ENVIRONMENT, useValue: dynamicEnv }])
      .bootstrapModule(AppModule)
      .catch((err) => console.error(err));
  });
};

main();
```

The `overrideEnv`, which is executed first in the `main` function, should be implemented as follows.

```typescript:override-env.ts
export const overrideEnv = async <T>(env: T): Promise<T> => {
  try {
    const response = await fetch('https://sample.com/api/client-env');
    const dynamicEnv: T = await response.json();
    for (const key in dynamicEnv) {
      if (Object.prototype.hasOwnProperty.call(dynamicEnv, key)) {
        const targetProp = env[key];
        if (targetProp !== undefined) {
          env[key] = dynamicEnv[key];
        }
      }
    }
  } catch (e) {}
  return env;
};
```

This `overrideEnv()` takes an environment variable as an argument, rewrites the value of the environment variable retrieved from the server if there is a matching property, and returns the rewritten environment variable. The internal processing of the function (how to retrieve dynamic environment variables and how to merge the retrieved environment variables) needs to be implemented according to the circumstances of each project.

## Using environment variables
The environment variable is now ready. In order to use this environment variable, DI using the `InjectionToken` that we defined earlier.

```typescript:sample-component.ts
import { Component, Inject, OnInit } from '@angular/core';
import { ENVIRONMENT } from 'src/main';

@Component({
  selector: 'app-sample',
  templateUrl: './sample.component.html',
  styleUrls: ['./sample.component.scss'],
})
export class SampleComponent implements OnInit {
  constructor(@Inject(ENVIRONMENT) env: Record<string, unknown>) {}

  ngOnInit(): void {}

  handleClick(): void {
    console.log(this.env);
  }
}
```

Of course, it is necessary to use the value of the environment variable provide to `'platform'`, so it is necessary to prohibit the direct reference to the environment variable from `environment.ts`. Although this is not the case in the example in this article, I think it is possible to specify `@deprecated` in `environment.ts` by TSDoc/JSDoc in the `environment` object itself.

# Summary
In order to handle environment variables dynamically, I introduced how to override environment variables in `main.ts` and Provide. As a side note, this time I used `main.ts` to inject the process before the Angular application is launched, but Angular provides `APP_INITIALIZER`, an `InjectionToken`, which can be used to inject the process before the `AppModule` bootstraps the `AppComponent` a little later. However, Angular provides a `InjectionToken` called `APP_INITIALIZER`, which allows you to insert a process before the `AppModule` bootstraps the `AppComponent`. This is basically a mechanism for initializing the service, and is not suitable (and probably not possible) for proving values, but it can be useful to know. If you want to use Service to get environment variables, you can initialize the environment variable Service with `APP_INITIALIZER`.

Dynamic Environment Variables in Angular

Angularにおける動的な環境変数の実現

# はじめに
AngularでServiceを作っているときに、共通の外部Interface（実体がありDIさせる）の元で状況に応じて内部実装を差し替えたい場合がある。こういうときの一つの方法としてStrategyパターンでServiceを実装すると良いという話があって、実際自分も試してみて良かったので内容をまとめておく。

元ネタは以下のng-japan onairの動画（36:30辺り）

<iframe width="560" height="315" src="https://www.youtube.com/embed/kf9sPXeuAok" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

# 実装
これから以下のような状況を仮定して実装する。

> - `TestService`:  
   外部Interface。利用者はこのServiceをDIする。ライブラリとして提供する場合はこのServiceだけを `public-api` に載せて、続く2つの実装クラスは基本的に公開しないようにする。そして、実装の切り替えは `'root'` でprovideする値 `'A'`, `'B'` によって行う。
>  - `TestAService`:  
   `'A'` がprovideされたときに使用されるTestServiceの1つ目の実装クラス。
>  - `TestBService`:  
   `'B'` がprovideされたときに使用されるTestServiceの2つ目の実装クラス。

## 外部Interface

```typescript:test-service.ts
import { Injectable } from '@angular/core';

import { TestAService } from './test-a.service';
import { TestBService } from './test-b.service';

export type Project = 'A' | 'B';

@Injectable({
  providedIn: 'root',
  useFactory: (
    project: Project,
    testAService: TestAService,
    testBService: TestBService
  ) => {
    switch (project) {
      case 'A':
        return testAService;
      case 'B':
        return testBService;
    }
  },
  deps: ['project', TestAService, TestBService],
})
export abstract class TestService {
  abstract greeting(): string;
}
```

- `useFactory` で `project` の値に応じて、`TestAService` もしくは `TestBService` を返すようにしている。ここでは `TestAService`, `TestBService` はシングルトンという前提で、`new` せず `deps` で既に存在しているインスタンスを利用するようにしている。もちろん `new` することも可能。
- `TestService` は外部Interfaceとして存在するだけなので、抽象クラスで実装し、メソッドも抽象メソッドとして定義する。

## 実装クラス
ほぼ同一の実装だが、一応 `TestAService` と `TestBService` の両方を載せておく。

```typescript:test-a.service.ts
import { Injectable } from '@angular/core';

import { TestService } from './test.service';

@Injectable({
  providedIn: 'root',
})
export class TestAService implements TestService {
  greeting(): string {
    return 'This is TestAService';
  }
}
```

```typescript:test-b.service.ts
import { Injectable } from '@angular/core';

import { TestService } from './test.service';

@Injectable({
  providedIn: 'root',
})
export class TestBService implements TestService {
  greeting(): string {
    return 'This is TestBService';
  }
}
```

- `implements TestService` で `TestService` をInterfaceとして利用する。これによりTSによるサポートが受けられ、実装漏れもなくなる。

## 条件のProvide （今回の実装特有の事情）
上記の例は `'project'` というstringリテラルをDI tokenとして `'A'`, `'B'` という値が `'root'` でprovideされている前提で実装している。なので、AppModuleのprovidersでこの値をprovideしておく。

```typescript:app.module.ts
// この場合TestServiceをDIするとTestAServiceが使われる
providers: [{ provide: 'project', useValue: 'A' }],　
```


AngularでServiceの実装クラス差し替え

# はじめに

Angular Materialにカレンダーから日付を選択する[Datepicker](https://material.angular.io/components/datepicker/overview)という部品がある。ただ、このDatepickerには厄介なところがあって、日付をISO 8601でしか管理できない。なので、フォームとして日付を例えば `yyyy/MM/dd` で管理したい場合に "部品の外部で" 自前で変換を差し込む必要がある。そしてここでもう一つ厄介なことに、DatepickerはValueAccessorをProvideしているため、同じ `<input>` に自作のDirective等でValueAccessorを追加でProvideすることができない。つまり、ValueAccessorの `onChange` や `writeValue` でよしなに値を書き換えるという方法は取れない。

最近このような状況があり、いくつか考えた結果割とシンプルに上記課題を解決する方法を思いついたのでまとめておく。

# 解決方法

## 実装の方針

以下の方針で実装した。

- Datepickerをバインドした `<input>` の値がISO 8601になってしまうのはもう諦めて、別途用意した `<input hidden>` に影響を押し込める
- 欲しいフォーマットの日付を入力するための `<input>` も用意し、`formControl` はこちらと結びつける
- Datepickerはカレンダーだけ利用させていただき、あとはイベントを拾ってそれを `formControl` に `patchValue` する
- Datepickerのカレンダーを開いたときにformControlの値と同期が取れていてほしいので、`<input hidden>` の `[value]` には `formControl.value`（今回フォーマットは `yyyy/MM/dd` の想定）をISO 8601に変換してバインドする

最後に上記をComponentとして共通化したものを紹介する。

## 共通Component化

これから作るComponentは `<mat-form-field>` の中に入るが、`<mat-fom-field>` は直接の子要素として `MatFormFieldControl` を実装したComponent（例えば `<input>`）を持つ必要があり、単にすべての `<input>` を共通Componentに押し込めてしまうとこの制約にひっかかる。

> `MatFormFieldControl` は `<mat-form-field>` 内で使えるinputを実装するためのinterfaceで結構制約が強い。このレベルの単純な機能を共通化するために実装するのはコストが見合わないのでそこまではやらないことにした。

そこで、改めて考えるとそもそも本質的にフォームとして働くのは `formControl` をバインドした `<input>` であって、Datepickerをバインドした `<input hidden>` の方はおまけである。よって、フォームとして働く方の　`<input>` にはそのまま残ってもらって、あくまでもカレンダー系部品をまとめる存在として共通Componentを定義する。この共通Componentはカレンダーからの入力で `formControl` に値をセットしないといけないので、`@Input()` デコレータで外から `formControl` だけもらえるようにしておく。

最終的な実装が以下である。

### 共通Component

```typescript:datepicker.component.ts
import { Component, Input } from '@angular/core';
import { AbstractControl, FormControl } from '@angular/forms';
import { MatDatepickerInputEvent } from '@angular/material/datepicker';

export const ISO_8601_REGEX = /^(\d{4})-(\d{2})-(\d{2})(?:T\d{2}:\d{2}:\d{2}(?:\.\d+)?(?:Z|(?:(?:\+|-)\d{2}:\d{2}))?)?$/;
export const CUSTOM_YMD_REGEX = /^(\d{4})\/(\d{2})\/(\d{2})$/;

@Component({
  selector: 'app-datepicker',
  templateUrl: './datepicker.component.html',
})
export class DatepickerComponent {
  @Input() control?: AbstractControl | null;

  public dateChangeHandler = (event: MatDatepickerInputEvent<Date>) => {
    if (!event.target.value) return;
    this.control?.setValue(
      this.convertToYYYYMMDDFromISODate(event.target.value?.toISOString())
    );
    this.control?.markAsTouched();
    this.control?.markAsDirty();
  };

  public dateInputHandler = (event: MatDatepickerInputEvent<Date>) => {
    if (!event.target.value) return;
    this.control?.setValue(
      this.convertToYYYYMMDDFromISODate(event.target.value?.toISOString())
    );
    this.control?.markAsTouched();
    this.control?.markAsDirty();
  };

  public convertToISODateFromYYYYMMDD(value: string): string {
    const found = value.match(CUSTOM_YMD_REGEX);
    if (!found || found[0] !== value) return value;
    return new Date(
      Number(found[1]),
      Number(found[2]) - 1,
      Number(found[3])
    ).toISOString();
  }

  private convertToYYYYMMDDFromISODate(value: string): string | null {
    if (ISO_8601_REGEX.test(value)) {
      const date = new Date(value);
      if (!isNaN(date.getTime())) {
        date.setMinutes(date.getMinutes() + 540);
        return date?.toISOString().replace(ISO_8601_REGEX, `$1/$2/$3`);
      }
    }
    return value;
  }
}
```

```html:datepicker.component.html
<input
  type="hidden"
  [matDatepicker]="picker"
  [value]="convertToISODateFromYYYYMMDD(control?.value)"
  (dateChange)="dateChangeHandler($event)"
  (dateInput)="dateInputHandler($event)"
/>
<mat-datepicker-toggle [for]="picker"></mat-datepicker-toggle>
<mat-datepicker #picker></mat-datepicker>

```

### 共通Componentを利用する側

こうする必然性はないが、`formGroup` から簡単に日付入力フォームのcontrolを参照できるようにgetterを定義しておく。直接 `formControl` を参照しても悪くない。共通Component側のinterfaceは `AbstractControl` を受け取るようにしたのでどちらでもいけるようになっている。

```typescript:.ts
get birthday(): AbstractControl | null {
  return this.sampleForm.get('birthday');
}
```

```html:.html
<mat-form-field appearance="fill">
  <mat-label>誕生日</mat-label>
  <input
    type="text"
    matInput
    placeholder="誕生日"
    id="birthday"
    name="birthday"
    required
    formControlName="birthday"
  />
  <app-datepicker matSuffix [control]="birthday"></app-datepicker>
</mat-form-field>
```

あくまでも表面に出ているところはただのtextの `<input>` なのでかなり扱いやすい。冒頭で少し触れた `<input>` でValueAccessorをProvideする、ということも可能になり、以下の記事で紹介した `ngx-mask` による入力値のフィルタリング等とも組み合わせることができる。

https://silurus.dev/articles/1PCqZpPS6qNIm1MFX9TjFM

# Overview

Angular Material has a component called [Datepicker](https://material.angular.io/components/datepicker/overview) that enables us to select a date from a calendar UI. However, this Datepicker has an annoying problem: it can only manage dates in ISO 8601 format. So if you want to manage dates in, for example, `yyyy/MM/dd` format, you need to insert your own conversions "outside the component". Another annoying thing here is that since Datepicker provides a ValueAccessor, it is not possible to provide an additional ValueAccessor in the same `<input>` by yourself. In other words, it is not possible to control the behavior of the form by your customized ValueAccessor that has customized `onChange` or `writeValue`.

Recently, I had a situation like this, and after some thought, I came up with a rather simple way to solve the above problem.

# Solution

## Implementation Policy

The implementation policy is as follows.

- Giving up on the fact that the value of `<input>` to which Datepicker is bound is ISO 8601 format, push that effect to a separately prepared `<input hidden>`.
- Have an another `<input>` for entering dates in the format we want, and bind the `formControl` to this.
- Use Datepicker only for the calendar UI, and manually picking up events to execute `patchValue` of `formControl`.
- For synchronization between Datepicker calendar and the formControl's value, bind `formControl.value` to `[value]` attribute of `<input hidden>` after converting format from `yyyy/MM/dd` to ISO 8601.

Finally, I introduce a common Component of the above.

## Commonalize by Component

The Component we are going to create will be inside `<mat-form-field>`, but `<mat-fom-field>` must have a Component that implements `MatFormFieldControl` (e.g. `<input>`) as a direct child element, and if we simply push all `<input>` into a common Component, it will be viplated by this restriction.

> `MatFormFieldControl` is an interface to implement inputs that can be used in `<mat-form-field>`, and it is quite restrictive. I decided not to go that far because it is not worth the cost to implement this Interface in order to make this level of simple functionality common.

When I think about it again, it is the `<input>` bound with `formControl` that essentially works as a form, and the `<input hidden>` bound with Datepicker is an extra.
Therefore, let the `<input>` that bound with `formControl` remain as it is, and define a common component as the entity that organizes calendar UI components. Since this common component needs to set the value of `formControl` by the input from the calendar UI, we make the common component can get `formControl` from outside with the `@Input()` decorator.

The final implementation is shown below.

### Implement Common Component

```typescript:datepicker.component.ts
import { Component, Input } from '@angular/core';
import { AbstractControl, FormControl } from '@angular/forms';
import { MatDatepickerInputEvent } from '@angular/material/datepicker';

export const ISO_8601_REGEX = /^(\d{4})-(\d{2})-(\d{2})(?:T\d{2}:\d{2}:\d{2}(?:\.\d+)?(?:Z|(?:(?:\+|-)\d{2}:\d{2}))?)?$/;
export const CUSTOM_YMD_REGEX = /^(\d{4})\/(\d{2})\/(\d{2})$/;

@Component({
  selector: 'app-datepicker',
  templateUrl: './datepicker.component.html',
})
export class DatepickerComponent {
  @Input() control?: AbstractControl | null;

  public dateChangeHandler = (event: MatDatepickerInputEvent<Date>) => {
    if (!event.target.value) return;
    this.control?.setValue(
      this.convertToYYYYMMDDFromISODate(event.target.value?.toISOString())
    );
    this.control?.markAsTouched();
    this.control?.markAsDirty();
  };

  public dateInputHandler = (event: MatDatepickerInputEvent<Date>) => {
    if (!event.target.value) return;
    this.control?.setValue(
      this.convertToYYYYMMDDFromISODate(event.target.value?.toISOString())
    );
    this.control?.markAsTouched();
    this.control?.markAsDirty();
  };

  public convertToISODateFromYYYYMMDD(value: string): string {
    const found = value.match(CUSTOM_YMD_REGEX);
    if (!found || found[0] !== value) return value;
    return new Date(
      Number(found[1]),
      Number(found[2]) - 1,
      Number(found[3])
    ).toISOString();
  }

  private convertToYYYYMMDDFromISODate(value: string): string | null {
    if (ISO_8601_REGEX.test(value)) {
      const date = new Date(value);
      if (!isNaN(date.getTime())) {
        date.setMinutes(date.getMinutes() + 540);
        return date?.toISOString().replace(ISO_8601_REGEX, `$1/$2/$3`);
      }
    }
    return value;
  }
}
```

```html:datepicker.component.html
<input
  type="hidden"
  [matDatepicker]="picker"
  [value]="convertToISODateFromYYYYMMDD(control?.value)"
  (dateChange)="dateChangeHandler($event)"
  (dateInput)="dateInputHandler($event)"
/>
<mat-datepicker-toggle [for]="picker"></mat-datepicker-toggle>
<mat-datepicker #picker></mat-datepicker>

```

### Use Common Component 

There is no need to do this, but define a getter so that you can easily refer to the control of a date input form from `formGroup`. It is not bad to refer to `formControl` directly. Since the interface of the common component is designed to receive `AbstractControl`, either is fine.

```typescript:.ts
get birthday(): AbstractControl | null {
  return this.sampleForm.get('birthday');
}
```

```html:.html
<mat-form-field appearance="fill">
  <mat-label>Birthday</mat-label>
  <input
    type="text"
    matInput
    placeholder="Birthday"
    id="birthday"
    name="birthday"
    required
    formControlName="birthday"
  />
  <app-datepicker matSuffix [control]="birthday"></app-datepicker>
</mat-form-field>
```

It is quite easy to handle, because the part that appears on the surface is just a text `<input>`. Also, it is possible to provide a ValueAccessor for `<input>`, which I mentioned at the beginning of this article, or combine it with [`ngx-mask`](https://www.npmjs.com/package/ngx-mask) to filter input values.

How to use Datepicker in Angular Material to handle dates in formats other than ISO 8601

Angular MaterialのDatepickerでISO 8601以外のフォーマットの日付を扱う方法

# はじめに

動的フォームを除いた部分で一般的に必要な機能を盛り込んだミニマムなサンプルを作ることができたので、その際に得た知見をまとめておく。タイトルの通り、フォームの実装にはReactive Formsを使っている。最終的なコードとデモは以下。

https://github.com/yukiyokotani/study-angular/tree/master/src/app/form-with-ngx-mask

https://yukiyokotani.github.io/study-angular/#/form-with-ngx-mask

# Reactive Formにおける登場人物

Reactive Formでいくつか部品が出てくるので、概念をまとめておく。登場するのは `FormGroup`, `FormControl`, `Validator` の3つで、親子関係として下図のようになる。

```
FormGroup
  ├─ FormControl (1)
  |    ├─ Validator (1-i)
  |    └─ Validator (1-ii)
  |
  ├─ FormControl (2)
  |    └─ Validator (2-i)
  |
  └─ Cross-field Validator (1)
```

まず `FormGroup` はフォームを司る存在で、HTMLの `<form>` と対応する。`FormGroup` は子として `FormControl` と `Cross-field Validator` を持つ。

`FormControl` はHTMLの `<input>` をViewとするならば、そのModelというべき存在で、`<input>` と一対一に対応し入力値を管理する。このとき、各 `<input>` に対するバリデーションは `FormControl` に `Validator` を設定することで実現できる。`FormControl` に `Validator` が設定されている場合、バリデーションが発火するのは `FormControl` に値がセットされるタイミングである。このセットのタイミングは `FormControl` の `updatedOn` のプロパティで設定することができる。

最後に `FormGroup` の子で説明を飛ばした `Cross-field Validator` について説明する。これは特定の `<input>` と一対一では紐付かない、複数の `<input>` を跨いで実行されるバリデーションを定義する。役割から自然なようにこれは `FormGroup` の直接の持ち物になる。

# Custom Validationの実装

## 単一のinputに対するCustom Validation

必須チェックや、文字列の長さの最大最小、数値の最大最小のような、基本的なValidatorについては`@angular/forms` の `Validator` クラスが提供している。それ以外のValidatorを用意したいときに、Validatorの実装が必要になる。

ここでは例として、日付のチェックのValidator実装を載せる。具体的には、FormControlにセットされた文字列が「`YYYY/MM/DD` のフォーマットになっているか」、「実際に存在する日付かどうか」の2点を判定し、どちらか一方でも不適なら不正な日付としてエラーオブジェクトを返す。

```typescript: dateValidator
// dayjsを使用している
export const dateValidator: ValidatorFn = (
  control: AbstractControl
): ValidationErrors | null => {
  const format = 'YYYY/MM/DD';
  const date = control.value;
  const isValid =
    typeof date === 'string' && dayjs(date, format).format(format) === date;
  return isValid ? null : { invalidDate: true };
};
```

FormControlにセットするためのValidatorなので、引数の `control` にはFormControlが入るものとして実装する。AngularのValidatorの仕様として返り値の型は `ValidatorFn` である必要がある。

> 上のサンプルではエラーがないときの返り値を `null` にしているが、 実装上 `undefined` のほうが良いと考えている。というのも、のちのちエラーメッセージの表示制御を行うときに、入力値にエラーがあるかどうかの状態をFormControlから取らないといけないのだが、FormControlのプロパティは至るところがNullableになっており、Optional Chainingした結果が `undefined` に化ける可能性がある。よって、最後の判定で `null` でもなく、`undefined` でもない、みたいなロジックを書かないといけなくなる。（`*ngIf`に渡すためには `boolean` に変換する必要がある）

## 複数のinputにまたがるValidation

### Validatorの定義

例としてパスワードを確認用も含めて2回入力させるフォームを考える。このとき両者は一致する必要があるが、このバリデーションは2つの `<input>` に跨るためCross-field Validationになる。単一の場合と同じくCross-field Validationも返り値の型は `ValidatorFn` になる。

```typescript: matchPasswordValidator
export const matchPasswordValidator: ValidatorFn = (
  control: AbstractControl
): ValidationErrors | null => {
  const password = control.get('password');
  const verifyPassword = control.get('verifyPassword');

  return password && verifyPassword && password.value !== verifyPassword.value
    ? { notMatchPassword: true }
    : null;
};
```

FormGroupにセットするValidatorなので、引数の `control` にはFormGroupが入るものとして実装する。

### ErrorStateMatcherの定義

Cross-field Validationにおいて追加で考えないといけないのが、ErrorStateMathcerの実装である。Cross-field Validationはそれだけではどの `<input>` とも紐付いていないので、エラーになったときにフォームとしてはエラー状態になるが、その原因となっている `<input>` （より正確には `<mat-form-field>`）がエラー状態にならない。`<mat-form-field>` がエラー状態にならないと、 `<mat-error>` のようなコンポーネントは表面的な `*ngIf` のロジック等に関わらず、エラーメッセージを表示しない作りになっている。よって、Cross-field Validationの対象となる `<input>` に対しては自分でErrorStateMathcerを定義して、エラー状態を適切に管理する必要がある。

サンプルは確認用パスワードのフォームに向けたErrorStateMatcherである。大雑把に言うと、「自分のFormControlがエラー状態になっている」もしくは「FormGroupが持つエラーを見て、当該のCross-field Validationがエラーになっている」場合にはエラー状態であることを示す `true` を返している。

```typescript: VerifyPasswordFormErrorStateMatcher
export class VerifyPasswordFormErrorStateMatcher implements ErrorStateMatcher {
  isErrorState(
    control: FormControl | null,
    form: FormGroupDirective | NgForm | null
  ): boolean {
    const isSubmitted = form && form.submitted;
    return (
      isSubmitted === true &&
      control !== null &&
      (control.errors !== null ||
        (form?.form?.errors?.notMatchPassword ?? false))
    );
  }
}
```

# 入力値のフォーマット（フィルタリング）

以下のように入力値に特定のフォーマットを強制したい場合は、`ngx-mask` を使うと便利である。

- 日付の入力で `2021/11/13` のように `/` 区切りのフォーマットを強制したい場合
- 数値の入力で表示上は `1,000,000` のように `,` (いわゆるthousands separator) を表示したい場合

https://www.npmjs.com/package/ngx-mask

`ngx-mask` はオプションで入力中にplaceholderを表示するかどうかや、最終的にFormControlにセットする値にフォーマットのための文字 (`/` や `,`) を含めるかどうかも設定することができる。

また、値のフィルタリングも簡単に実装することができる。

# 入力値のトリミング・フィルタリング（独自実装）

少し別の視点で、独自に入力値をトリミング、フィルタリングしたい場合のDirectiveの実装について書く。ただ、この内容は `ngx-mask` を利用していれば基本的に不要な話ではある。

このあと実装をベタッと貼り長くなるため、先に説明する。FormControlが `<input>` にアクセスするために、VlueAccessorというクラスを経由している。無意識でフォーム実装しているうちは、基本的にValueAccessorはデフォルトのものが使われているが、一部Angular MaterialのDatePickerなんかはVlueAccessorを独自にProvideしていたりする。

このDirectiveは `<input>` のレイヤーでカスタマイズしたValueAccessorをProvideし、FormControlが `<input>` にアクセスする処理に介入する。

知っておくべきことは3つで、
- DefaultValueAccessorを継承して実装する
- View → Model方向の更新は `'change'`, `'blur'` イベントをトリガーに行い、superクラス (DefaultValueAccessor) の `onChange`, `onTouched` を利用する
- Model → View方向の更新はsuperクラスの `writeValue` をオーバーライドして定義する

興味があればコピーして `<input>` にセットしてみて欲しい。  
引数はフィルタリングしたい文字の配列を渡す。例えば、以下のように使う。

```typescript:typescript
removeCharacters = ['-', '^', ',', '.', '\\', '/', ' '];
```

```html:html
<input
  matInput
  placeholder="ユーザー名"
  id="name"
  name="name"
  formControlName="name"
  [appTrimValue]="removeCharacters"
/>
```

Directiveの実装

```typescript: TrimValueDirective
import {
  Directive,
  HostListener,
  forwardRef,
  Provider,
  Input,
} from '@angular/core';
import { DefaultValueAccessor, NG_VALUE_ACCESSOR } from '@angular/forms';

const TRIM_VALUE_ACCESSOR: Provider = {
  provide: NG_VALUE_ACCESSOR,
  useExisting: forwardRef(() => TrimValueDirective),
  multi: true,
};

/**
 * テキスト入力フォームの入力値をblur時にトリム・フィルタリングするためのDirective
 */
@Directive({
  selector: `[appTrimValue]`,
  providers: [TRIM_VALUE_ACCESSOR],
})
export class TrimValueDirective extends DefaultValueAccessor {
  private needEscapeCharacters = [
    '/', '\\', "'", '"', '.', '*', '+', '?', '^', '$', '-', '|', '(', ')', '{', '}', '{', '}',
  ];

  /** filterしたいパターンのリスト */
  private _filterPattern?: RegExp;
  @Input() set appTrimCustomValue(trimPattern: string[]) {
    this._filterPattern = new RegExp(
      `(${trimPattern.reduce((prev, curr) => {
        const escapedCurr = this.needEscapeCharacters.includes(curr)
          ? '\\' + curr
          : curr;
        return `${prev}|${escapedCurr}`;
      }, '')})+`,
      'g'
    );
  }

  @HostListener('input', ['$event.target.value'])
  ngOnChange = (val: string) => {
    let filteredVal = val;
    if (this._filterPattern) {
      filteredVal = filteredVal.replace(this._filterPattern, '');
    }
    this.onChange(filteredVal.trim());
  };

  @HostListener('blur', ['$event.target.value'])
  ngOnBlur = (val: string) => {
    let filteredVal = val;
    if (this._filterPattern) {
      filteredVal = filteredVal.replace(this._filterPattern, '');
    }
    this.writeValue(filteredVal.trim());
    this.onTouched();
  };

  writeValue(value: any): void {
    if (typeof value === 'string') {
      value = value.trim();
    }

    super.writeValue(value);
  }
}
```

上記Directive実装の参考：

https://github.com/khashayar/ng-trim-value-accessor/blob/master/src/trim-value-accessor.ts

# 送信済みフラグ

最後にフォームの送信済みフラグの実装について書く。Angularの[AbstractControl](https://angular.io/api/forms/AbstractControl)（FormGroup, FormControlの基底クラス）は `touched` （フォーカスされたかどうか）、`dirty`（編集されたかどうか）のフラグは持っているものの、フォームが送信されたかどうかのフラグを持っていない。しかし、フォームの実装上、エラーメッセージの表示条件などで初期値が `false` でフォームが送信されたときに `true` になるようなフラグが欲しい場合がある。このようなフラグはテンプレートの `<form>` タグにテンプレート変数を埋め込んで参照を持ち（`#ngForm="ngForm"`）、`ngForm.submitted` を見る方法が一般的なようである。個人的には `formGroup` に加えて `ngForm` を `<form>` に渡すのが参照関係を複雑化させているようで好きではなかったので、単純にComponentにboolean型のメンバー変数、例えば `isSubmitted` を定義して使うだけでもよいのではないかと思ってそうしている。その場合には、`isSubmitted` の `true` への書き換えは `(ngSubmit)` にバインドした送信のメソッドで行う。また、送信後にフォームが再編集されたら `isSubmitted` を `false` に更新したいといった要件にも対応することができる。この場合は、FormGroupが持つ `valueChanges` というObservableを購読し、そのsubscriber関数の中で `false` への更新を行う。

Articles

NgComponentOutletで生成したComponentにパラメータを渡す

Angularにおける動的な環境変数の実現

AngularでServiceの実装クラス差し替え

Angular MaterialのDatepickerでISO 8601以外のフォーマットの日付を扱う方法

AngularのReactive Formsを使ったフォーム実装まとめ