# はじめに
昨今のReactのフォームライブラリではスタンダードになっているReact Hook Form (v7) と、これもReactのプロジェクトではよく用いられるMUI (v5)の各種入力部品を組み合わせて、汎用的に使用できる入力部品を作ってみた。テキストの入力においては純粋なテキスト (string型) の入力と、数値 (number型) の入力を分けたくなるのが常なので、MUIの `TextField` をベースに、`MuiTextField` と `MuiNumericField` の2つを用意してこれらを区別した。また、数値の入力部品では入力値をフォーマットして表示したい場面も多いので、`MuiNumericField` にはreact-number-formatも組み込んで、入力値のフォーマットができるようにした。

> info:執筆時の依存バージョン (最終更新2022/12/17)
> 
> - React v18.2.0
> - MUI v5.8.4
> - React Hook Form v7.30.0
> - react-number-format v5.1.2

先に最終的なデモを貼っておく。

<iframe src="https://yukiyokotani.github.io/react-hook-form/"
  style="width:100%; height:630px; border:0; border-radius: 4px; overflow:hidden;"
  title="MUI Input Components Linked to React Hook Form"
  allow="accelerometer; camera; encrypted-media; geolocation; gyroscope; midi; payment; usb; xr-spatial-tracking"
  sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
></iframe>

一連のファイルを置いたGitHubリポジトリは以下になる。

https://github.com/yukiyokotani/react-hook-form

**現状形になっている部品一覧**

- [MuiTextField](https://github.com/yukiyokotani/react-hook-form/blob/main/src/mui-form/components/MuiTextField.tsx)
- [MuiNumericField](https://github.com/yukiyokotani/react-hook-form/blob/main/src/mui-form/components/MuiNumericField.tsx)
- [MuiDatePicker](https://github.com/yukiyokotani/react-hook-form/blob/main/src/mui-form/components/MuiDatePicker.tsx)
- [MuiCheckbox](https://github.com/yukiyokotani/react-hook-form/blob/main/src/mui-form/components/MuiCheckbox.tsx)
- [MuiSelect](https://github.com/yukiyokotani/react-hook-form/blob/main/src/mui-form/components/MuiSelect.tsx)
- [MuiAutocomplete](https://github.com/yukiyokotani/react-hook-form/blob/main/src/mui-form/components/MuiAutocomplete.tsx)

以降では今回のインターフェース設計の思想と、実装時に得られた雑多な情報について軽く書きとめおく。この汎用部品を使いたい方はすぐ後の「利用者側から見たインターフェース」で使い方の雰囲気だけさっと眺めてGitHubに置いた[サンプルのフォーム実装](https://github.com/yukiyokotani/react-hook-form/blob/main/src/mui-form/MuiForm.tsx)を見てもらうのがいいと思う。

# インターフェース
## 利用者側から見たインターフェース
インターフェースを紹介するために、一番シンプルな `MuiTextField` (string型のテキスト入力部品) の利用方法を紹介する。`MuiTextField` 以外の部品も同じインターフェイス設計になっているので、`MuiTextField` が分かれば他の部品も簡単に利用できるようになっている。

今回の汎用部品は型引数としてフォームオブジェクトの型を取るようにした。フォームの型はTypeScriptでReact Hook Formを使う場合は必ず定義する (そして `useForm` の型引数に渡す) ことになるので、同じものをそのまま渡せば良い。ここで型を渡すと、入力部品の `name` のPropsに渡した文字列が、ちゃんとフォームのkeyとして存在するかチェックされる。

```javascript:MuiTextFieldの使用例
<MuiTextField<FormData>
  name='name'
  control={control}
  rules={{
    required: '必須項目です。',
    maxLength: {
      value: 5,
      message: '5文字以内で入力してください。'
    }
  }}
  config={{
    displayErrorMessage: true
  }}
  muiProps={{
    textFieldProps: {
      label: '名前',
      fullWidth: true
    }
  }}
/>
```

上記の通り、Propsは大きく3つに分けて設計した。
- **React Hook Formで定義されているProps**  
  今回はこれを入力部品のベースのインターフェースとする
- **MUIの部品に対して定義されているProps**  
  今回はこれを `muiProps` としてまとめる
- **部品の提供者が追加で提供する設定項目のProps**  
  今回はこれを `config` としてまとめる

上の例で言うと、`name`, `control`, `rules`がReact Hook Form向けのインターフェイスである。今回の汎用部品ではこれを設計のベースにしているので、ネストしないPropsとして渡すことができる。このうち `control` と `name` はReact Hook Formによる制御において必須なので、Propsとしても必須にしている。一方で `rules` は必須ではなく、[Zod](https://github.com/colinhacks/zod)等のschemaライブラリを使ってフォームのschemaを定義し、`useForm` にschemaを渡す形でもバリデーションが実現できるようになっている。勿論バリデーションなしでも良い。

## 提供者側から見たインターフェース
とにかくPropsが多いので、3つの大きなまとまりで分けて管理するようにした。一つ目は今回主役となっているReact Hook FormのProps、2つ目はMUIのComponentのProps、3つ目が部品を提供する側が独自で組み込みたいオプションを提供するためのPropsである。

### React Hook FormのProps
React Hook Formのインターフェイスは `UseControllerProps` としてライブラリから提供されている。このPropsはインターフェースとして最表面に出ていて欲しい（ネストして欲しくない）ので、今回作る部品のPropsはこの型との交差型にすることにした。上記のサンプルで言うと、`name`, `control`, `rules`はReact Hook Formが公開しているインターフェイスで定義されたPropsである。

### MUI ComponentのProps
MUIのPropsは部品によっては複数必要になる。例えばAutocompleteではAutocomplete自体のPropsに加えて、内部に持つTextFieldのProps　（フォームの幅やラベルなど）　も渡せるようにしたい。よって、これらはオブジェクトに整理して、PropsのmuiPropsという口で渡せるようにした。React Hook FormのPropsとMUIのPropsは同名のものが多く衝突する可能性が高い（そして意図せず衝突するとバグる）ので、最初から分けてバグを生む可能性を排除した。

### 部品提供者が独自に提供する設定項目
提供者が独自で組み込みたいオプションを提供するためのPropsについても、MUIのPropsと同様、オブジェクトにまとめて、configという口で渡せるようにした。react-number-formatのProps (`NumberFormatPropsBase`) は意味的にはここに収まるのが良いと考えたので、`MuiNumberField` のconfigについては `NumberFormatPropsBase` との交差型になっている。


# Introduction
I tried to create an input component that can be used universally by combining React Hook Form (v7), which has become a standard in the recent React form libraries, and various input components of MUI (v5), which is also commonly used in React projects. In the text input, it is always necessary to separate pure text (string type) input from numeric (number type) input, so based on the MUI `TextField`, I prepared two input components, `MuiTextField` and `MuiNumericField`, to distinguish between them. Also, since there are many situations where you want to format and display input values in numeric input parts, I also incorporated react-number-format into `MuiNumericField` so that you can format the input values.

> info:Dependent version at the time of writing (last updated on Dec. 17, 2022)
> 
> - React v18.2.0
> - MUI v5.8.4
> - React Hook Form v7.30.0
> - react-number-format v5.1.2

I'll post the final demo first. (Sorry for the Japanese sample.)

<iframe src="https://yukiyokotani.github.io/react-hook-form/"
  style="width:100%; height:630px; border:0; border-radius: 4px; overflow:hidden;"
  title="MUI Input Components Linked to React Hook Form"
  allow="accelerometer; camera; encrypted-media; geolocation; gyroscope; midi; payment; usb; xr-spatial-tracking"
  sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
></iframe>

GitHub repository is below. (Commented in English.)

**List of currently available parts**.

- [MuiTextField](https://github.com/yukiyokotani/react-hook-form/blob/main/src/mui-form/components/MuiTextField.tsx)
- [MuiNumericField](https://github.com/yukiyokotani/react-hook-form/blob/main/src/mui-form/components/MuiNumericField.tsx)
- [MuiDatePicker](https://github.com/yukiyokotani/react-hook-form/blob/main/src/mui-form/components/MuiDatePicker.tsx)
- [MuiCheckbox](https://github.com/yukiyokotani/react-hook-form/blob/main/src/mui-form/components/MuiCheckbox.tsx)
- [MuiSelect](https://github.com/yukiyokotani/react-hook-form/blob/main/src/mui-form/components/MuiSelect.tsx)
- [MuiAutocomplete](https://github.com/yukiyokotani/react-hook-form/blob/main/src/mui-form/components/MuiAutocomplete.tsx)

From here, we will summarize the philosophy behind the interface design, the information we obtained for each library while creating this component, and the points that stuck out in the implementation.　If you want to use the generic input component implemented here, you can have a quick look at the "Interface from the User's Point of View" to get an idea of how to use it, and then look at the [sample form implementation](https://github.com/yukiyokotani/react-hook-form/blob/main/src/mui-form/MuiForm.tsx) on GitHub.

## Interfaces
## Interface from the User's Point of View
To introduce the interface, we will show you how to use the simplest `MuiTextField` (a text input component of type `string`). The other components except for `MuiTextField` have the same interface design, so if you know `MuiTextField`, you can use the other components easily.

The component now takes the type of the form object as its type argument. The type of the form is always defined (and passed to the type argument of `useForm`) when using React Hook Form in TypeScript, so you can pass the same type as it is. If you pass the type here, it will be checked if the string you pass to the `name` props of the input component exists as a key of the form.

```javascript:Example of MuiTextField use
<MuiTextField<FormData, 'username'>
  name='username'
  control={control}
  rules={{
    required: 'Enter your username.',
    maxLength: {
      value: 10,
      message: 'Enter up to 10 characters.'
    }
  }}
  config={{
    displayErrorMessage: true
  }}
  muiProps={{
    textFieldProps: {
      label: 'Username',
      fullWidth: true
    }
  }}
/>
```

Props can be divided into three main categories.
- Props defined in React Hook Form. We will use this as the base interface for input components.
- Props defined for MUI components. This time, we will group them as `muiProps`.
- Additional configuration items for the part provided by the part provider. We will summarize this as `config`.

In the example above, `name`, `control`, and `rules` are the interfaces for the React Hook Form. In this generic part, since this is the base of the design, we can pass them as non-nested props. Among them, `control` and `name` are required for control by React Hook Form, so they are also required as Props. On the other hand, `rules` is not required, and validation can be realized by defining a form schema using a schema library such as [Zod](https://github.com/colinhacks/zod) and passing the schema to `useForm`. Of course, it is also possible without validation.

## Interface from the Provider's Point of View
Since there are a lot of Proposals, I decided to divide them into three major groups to manage them. The first is the React Hook Form Prop, which is the main component of this project, the second is the MUI Component Prop, and the third is the Prop to provide options that the component provider wants to incorporate on their own.

### Props of React Hook Form
The interface of React Hook Form is provided by the library as `UseControllerProps`. Since I want this Props to be on the top surface as an interface (I don't want it to be nested), I decided to make the Props of the part I'm going to create an intersection type with this type. In the above sample, `name`, `control`, and `rules` are Props defined in the interface exposed by React Hook Form.

### Props for MUI Component
Some parts require multiple MUI props. For example, in Autocomplete, in addition to Autocomplete's own Props, we want to be able to pass the internal TextField's Props (form width, label, etc.). Therefore, we organized them into objects, and made it possible to pass them through a mouth called muiProps of Props. Therefore, we have eliminated the possibility of creating bugs by separating them from the beginning.

### Configuration items provided independently by component providers
Props to provide options that providers want to incorporate into their own components are also grouped into an object and can be passed as config, just like props in the MUI. (`NumberFormatPropsBase`) is semantically better to fit here, so the `MuiNumberField` config is crossed with `NumberFormatPropsBase`.


Create an input component that combines React Hook Form with MUI, react-number-format

React Hook Form, MUI, react-number-formatを組み合わせた汎用入力部品を作る

# はじめに
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における動的な環境変数の実現

# i18n対応
昨日このブログをi18n (internationalization) 対応させた。i18n対応はNext.jsが公式にサポートしており、`next.config.js` に適当な設定を書くだけで済む。これについてはネット上にたくさん情報があるのでこの記事では省略する。この記事ではi18n対応にあたり、sitemap生成で必要になった修正について記録しておく。なお、以下の話はアプリをVercelにデプロイすることを前提としている。執筆時点のNext.jsのバージョンは `12.0.1` である。

# sitemap生成

## i18n対応前
このブログのsitemap生成には以下のライブラリを使用している。

https://www.npmjs.com/package/next-sitemap

このライブラリを使えば、あとは `sitemap.config.js` を定義してビルドスクリプトに少し手を加えればsitemap.xmlの生成を行うことができる。これについてもネット上にたくさん情報がある。i18n対応前のこのブログの `sitemap.config.js` とビルドスクリプトは以下の通りだった。

```javascript:sitemap.config.js
module.exports = {
  siteUrl: 'https://silurus.dev',
  generateRobotsTxt: true,
  sitemapSize: 7000,
  outDir: './out'
};
```

```json:package.json
"scripts": {
  "build": "next build && next export && next-sitemap --config sitemap.config.js",
},
```

上記の設定で、sitemapには [https://silurus.dev/sitemap.xml](https://silurus.dev/sitemap.xml) でアクセスできた。

## i18n対応後
Next.jsでi18n対応すると、`next export` が行えなくなるため、まず `package.json` のビルドスクリプトを以下のように修正する必要がある。

```json:package.json
"scripts": {
  "build": "next build && next-sitemap --config sitemap.config.js",
},
```

すると、芋づる式に `sitemap.config.js` で `outDir: './out'` と書いているところが不整合になる。`out` ディレクトリは `next export` の結果生成されるディレクトリなので、`next build` だけではディレクトリが存在しない。このままだとデプロイしても静的リソースにsitemap.xmlが含まれず、もとのURLではアクセスできなくなる。

というわけで、`sitemap.config.js` は以下のように修正する必要がある。

```javascript:sitemap.config.js
module.exports = {
  siteUrl: 'https://silurus.dev',
  generateRobotsTxt: true,
  sitemapSize: 7000,
  outDir: './public'
};
```

`public` フォルダに置いているものはビルド後 `ベースパス/ファイル名` でアクセスできるので、これで引き続き同一のアドレスでアクセスできるようになる。

このサイトであれば、当初の[https://silurus.dev/sitemap.xml](https://silurus.dev/sitemap.xml) のままアクセスできる。

# i18n support
Yesterday, I added i18n (internationalization) setting to this blog. i18n is officially supported by Next.js, and all you have to do is write the appropriate settings in `next.config.js`. There is a lot of information about this on the internet, so I won't go into it in this article. In this article, I'd like to write about modifications required for sitemap generation to support i18n. The following story assumes that the application is deployed to Vercel. The version of Next.js at the time of writing is `12.0.1`.

# Sitemap generation

## Before i18n support
The following library is used to generate sitemap for this blog.

https://www.npmjs.com/package/next-sitemap

If you use this library, you can generate sitemap.xml by defining `sitemap.config.js` and modifying the build script a little. Before i18n support, this blog's `sitemap.config.js` and build script was as follows.

```javascript:sitemap.config.js
module.exports = {
  siteUrl: 'https://silurus.dev',
  generateRobotsTxt: true,
  sitemapSize: 7000,
  outDir: '. /out'
};
````json:package.json

```json:package.json
"scripts": {
  "build": "next build && next export && next-sitemap --config sitemap.config.js",
},
```

With the above configuration, sitemap could be accessed with [https://silurus.dev/sitemap.xml](https://silurus.dev/sitemap.xml).

## After i18n support
After adding i18n settings in Next.js project, `next export` is not available, so you need to modify the build script of `package.json` as follows.

```json:package.json
"scripts": {
  "build": "next build && next-sitemap --config sitemap.config.js",
},
```

Then, in `sitemap.config.js`, `outDir: '. /out'` is inconsistent. The `out` directory is a directory created as a result of `next export`, so the directory does not exist in `next build` alone. If this is the case, sitemap.xml will not be included in static resources after deployment on Vercel, and it will not be accessible with the original URL.

So, you need to modify `sitemap.config.js` as follows.

```javascript:sitemap.config.js
module.exports = {
  siteUrl: 'https://silurus.dev',
  generateRobotsTxt: true,
  sitemapSize: 7000,
  outDir: '. /public'; }
};
```

If you put it in the `public` folder, you can access it with the `base path/file name` after the build, so you can continue to access it with the same address.

In the case of this site, you can access to sitemap with the original address: [https://silurus.dev/sitemap.xml](https://silurus.dev/sitemap.xml)

Generating sitemap.xml with i18n support in Next.js

Next.jsでi18n対応した場合のsitemap.xml生成

# はじめに

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以外のフォーマットの日付を扱う方法

# はじめに

TypeScriptで引数と返り値が配列となる関数に型付けする方法についてまとめる。この記事の内容は先日Qiitaに書いた以下の記事がベースになっているが、あちらは最終的な結果から逆算して必要最低限で書いたところがあった。なので、こちらではもう少し初歩の内容から始めて、色々書いていきたいと思う。

https://qiita.com/yokotani/items/2ce52e2f47dbd892c591

# TypeScriptで配列を引数に取り配列を返す関数を型定義する

## 配列の要素がプリミティブ型の場合

まず初歩の内容として、`string[]` 型の配列を引数に取り、そのまま `string[]` 型の配列を返すような関数を考える。この関数は以下のように型定義できる。

> 本記事では引数の配列を `beforeList`, 返り値の配列を `afterList` と名付け、関数の名前を `convert` としている。

```typescript
function convert(beforeList: string[]): string[];
```

これは配列の記法を知っていれば書けるのでなんてことはないと思う。では次に配列の要素が複数の型を取りうる場合について考える。

## 配列の要素を複数のプリミティブ型に対応させる場合

複数の型に対応することを考えると、自分がどういう型を定義したいのかもう少し詳細を詰める必要がある。例えば、「引数の配列の要素は `string` 型でも `number` 型でも良く、返り値の配列には引数と同じ型をつける」ということを考えたときに、以下の2つの場合が考えられる。

- 配列の要素に `string` 型と `number` 型が入り乱れている場合
- 配列の要素は `string` 型か `number` 型のどちらか一方である場合

### 配列の要素にstring型とnumber型が入り乱れている場合

これも初歩的な知識で書くことができる。

```typescript
function convert(beforeList: Array<string | number>): Array<string | number>;

const afterlist = convert([1, 'a', 2, 'b']); // afterList は Array<string | number> 型になる
```

Union型を使うことで、`string` 型もしくは `number` 型という要素の型を表現できる。

### 配列の要素はstring型かnumber型のどちらか一方である場合

この場合は先程の型定義でも問題ないが、より良いのはジェネリクスを使って型定義する方法である。この例は先程の例とは異なり関数の使用時に要素の型を `string` 型もしくは `number` 型のどちらかに絞り込むことができるはずである。よって型でもそれを表現したい。ジェネリクスを使うことで、「`string` 型の配列を受けて `string` 型の配列を返す関数」と「`number` 型の配列を受けて `number` 型の配列を返す関数」を1つの型定義で表現することができる。そして、`string` 型なのか `number` 型なのか、の絞り込みはその関数が使用されるときに引数の型から推論する。引数から型を推論するために、ここでは引数の型を型変数 `T` で受けることにする。

```typescript
function convert<T>(beforeList: T): T; // 返り値は引数と同じ T 型とする
```

上の例では、先程まで `string | number` で定義していた関数の引数を `T` という型変数で受けている。`T` が型変数であることを示すために、関数引数 `()` の前に `<T>` という宣言を追加している。引数の型を `T` という変数で受けたことで、返り値の型にその型情報を使うことができる。

これでこの `convert` という関数は引数にどんな型でも取ることができ、それはそのまま返り値の型となった。しかし、この例でやりたかったことは `string` 型の配列、もしくは `number` 型の配列を受け取り、返り値としてそれぞれ引数と同じ型の配列を返すことだった。「引数にどんな型でも取ることができる」というのでは型として緩い。そこで型引数 `T` に次のようにして制約を与える。

```typescript
function convert<T extends string[] | number[]>(beforeList: T): T;
```

これにより、先程宣言した型引数 `T` は `extends string[] | number[]` という制約を満たさなければならなくなった。この `extends` が意味するところは、`T` 型が `string[] | number[]` の部分型かどうか、言い換えると、`T` 型を `string[] | number[]` 型に代入できるかどうか、を引数の制約にするということである。いま、引数に想定しているのは `string[]` 型、もしくは `number[]` 型なので、これらは `string[] | number[]` の部分型という条件を満たしている。逆に、例えば `T` に `any` や `string` が入ると、それらは `string[] | number[]` の部分型ではないので、制約違反ということになり、型エラーになる。よって、これは狙い通りの制約である。

> React のような完成されたライブラリを使っている限りは、このレベルの型定義が必要になる場面はまず無いので、この辺りがTypeScript型パズルの最初のハードルになると思っている。自分がそうだったけれど、型定義自体を目的に勉強しているうちはなかなか身につかず、手段として必要になったときに意外とすっと習得できたりする。

## 配列の要素にstring型とnumber型が入り乱れている場合の発展

ここからは前に考えた `string` 型と `number` 型が入り乱れている場合の発展として、その個々の要素の型情報を維持したまま返り値に型をつける方法を考える。これを実現するためには、これまでの配列型ではなく、Tuple型を使う必要がある。Tuple型に起因する制限として、これから定義する関数はプログラム実行時に動的に生成した配列を引数に渡すことはできない。ただ、コーディング時に要素数が確定している配列に対してはそれをTuple型で定義することで引数に渡すことができる。

> TypeScriptのTuple型は配列型の特殊系で、要素数が固定されており、それぞれの要素の型が定義されたものと捉えることができる

このような型はVariadic Tuple TypesというTypeScriptの機能を使って以下のように書くことができる。

```typescript
function convert<T extends ReadonlyArray<string | number>>(beforeList: [...T]): [
    ...{ [K in keyof T]: T[K] extends string ? string : number}
];

const afterList = convert([1, 'a', 1]) // afterList は [number, string, number] 型になる
```

上では `convert` の引数の中で `[1, 'a', 1]` と書いているので、これがTuple型と判断されている。Variadic Tuple Typesのポイントは 引数を `[...T]` という型で受けることができている点である。つまり、引数は何かしらのTuple Tを展開したものであるとして、引数の要素全体を `T` で受ける。受けた後は `T` の各要素にインデックスアクセスすることができ、例のように `extends` で `stirng` の部分型かどうかを見て、返り値の型を出し分けることができる。

なお、引数のタプルを関数の外で定義する場合は以下のように書く。

```typescript
const beforeList: [number, string, number] = [1, 'a', 1];
const afterList = convert(beforeList);
```

## 配列の要素がジェネリック型の場合

上の例をもう少し応用して、あるジェネリック型のTupleを引数に取り、型変数を引き継いだまま別のジェネリック型のTupleを返す関数を型定義することができる。これについては最初にも貼った以下の記事で書いているので、結果だけ書くことにする。

https://qiita.com/yokotani/items/2ce52e2f47dbd892c591

```typescript
// サンプルとして Before<T> 型と After<T> 型を定義
type Before<T> = {
    type: 'before',
    value: T,
}

type After<T> = {
    type: 'after',
    value: T,
}

// convert の型定義 (関数本体の実装は省略)
function convert<T extends ReadonlyArray<Before<unknown>>>(beforeList: [...T]): [
    ...{ [K in keyof T]: T[K] extends Before<infer U> ? After<U> : never }
]

// テスト
const before1: Before<number> = {
    type: 'before',
    value: 1,
}

const before2: Before<string> = {
    type: 'before',
    value: 'string',
}

const afterList = convert([before1, before2]); // [After<number>, After<string>] 型になっている
```

Tuple型で定義できるもの、という制約はあるものの、JSライブラリの中にはオブジェクトの配列から別オブジェクトの配列を作る関数を提供しているものがあったりするので、そういう関数に型定義する場面ではこの方法は役に立つことがあると思う。

# Overview

In this article, I will show how to type a function whose arguments and return values are arrays by TypeScript. This content is based on the following article I wrote on Qiita the other day, but since that article was written with the minimum necessary content based on the final result, I'd like to start with some more elementary content and write about various things here.

https://qiita.com/yokotani/items/2ce52e2f47dbd892c591

# Type-defining a function that takes an array as an argument and returns an array in TypeScript

## When array elements are of primitive type

First of all, let's consider a function that takes an array of type `string[]` as an argument and returns an array of type `string[]`. This function can be typed as follows.

> In this article, the array of arguments is named `beforeList`, the array of return values is named `afterList`, and the name of the function is `convert`.

```typescript
function convert(beforeList: string[]): string[];
```

This can be written if you know array notation, so it should be no problem. Next, let's consider the case where the elements of an array can be of multiple types.

## When multiple primitives appear as elements of an array

Considering the support for multiple types, you need to work out a little more details about what type you want to define. For example, if you think "the elements of the array of arguments can be of type `string` or `number`", the following two cases are possible.

- When `string` and `number` types are mixed in array elements
- If you have an array whose elements are either `string` or `number`, but you want to support both cases with a single type definition

### When array elements of type string and number are mixed together

This can also be written with elementary knowledge.

```typescript
function convert(beforeList: Array<string | number>): Array<string | number>;

const afterlist = convert([1, 'a', 2, 'b']); // AfterList will be of type Array<string | number
```

Since we only use the Union type, the level of detail is the same as in the first example.

### If the elements of an array are of either string or number type, but you want to support both cases with a single type definition

In this case, the previous type definition is fine, but a better way is to use generics to define the type. The difference between the previous example and this one is that in this case, we want to narrow down the type of the element to either `string` or `number`, while the previous example leaves the ambiguity of choosing either `string` or `number` for the array element. To do this, we need to infer the type from the arguments. For this purpose, we will take the type of the argument as the type variable `T`.

```typescript
function convert<T>(beforeList: T): T; // The return value should be the same type as the argument, T.
```

In the above example, the argument of the function which was defined as `string | number` is received as a type variable `T`. To show that `T` is a type variable, the declaration `<T>` is added before the function argument `()`. Because the type of the argument is received in the variable `T`, the information can be used for the type of the return value.

Now the function `convert` can take any type as an argument, and it will be the type of the return value. However, what we initially wanted to do was to take an array of type `string` or `number` and return an array of the same type as the arguments. If the argument can be any type, it is too loose a type. So, to constrain the type argument `T`, we write it as follows.

```typescript
function convert<T extends string[] | number[]>(beforeList: T): T;
```

Now, the type argument `T` that we just declared must satisfy the constraint `extends string[] | number[]`. What this `extends` means is that the constraint of the argument is whether `T` is a subtype of `string[] | number[]`, in other words, whether `T` can be assigned to `string[] | number[]`. Now, we assume that the arguments are of type `string[]` or `number[]`, so they satisfy the condition that they are subtypes of `string[] | number[]`. On the other hand, if, for example, `T` contains `any` or `string`, they are not subtypes of `string[] | number[]`, so the constraint is violated and a type error occurs. Therefore, this is the constraint we are aiming for.

> As long as you're using a complete library like React, you're unlikely to need this level of type definition, so I think this will be the first hurdle for TypeScript type puzzles. As I did, it's hard to learn type definitions when you're studying them for their own sake, but when you need them as a means to an end, you can learn them surprisingly quickly.

## Development of the case where array elements of type string and number are mixed up

In this section, we will consider how to add a type to the return value while maintaining the type information of each element, as an extension of the case where the `string` and `number` types are mixed up. In order to achieve this, we need to use the Tuple type instead of the array type. Therefore, the function we are going to define cannot pass a dynamically generated array as an argument at program execution time. However, if the number of elements in the array is fixed at the time of coding, it can be passed as an argument by defining it with the Tuple type.

> The TypeScript tuple type can be thought of as an array type in which the number of elements is fixed and the type of each element is defined.

Such types can be written as follows using a TypeScript feature called Variadic Tuple Types.

```typescript
function convert<T extends ReadonlyArray<string | number>>(beforeList: [...T]): [
    ...{ [K in keyof T]: T[K] extends string ? string : number}
];

const afterList = convert([1, 'a', 1]) // afterList will be of type [number, string, number].
```

In the above, `[1, 'a', 1]` is written in the argument of `convert`, so it is judged to be a tuple type. The point of Variadic Tuple Types is that the argument can be received in the type `[...T]`. That is, the argument is assumed to be an expansion of some Tuple T, and the whole element of the argument is received in `T`. After receiving the argument, each element of `T` can be indexed, and the type of the return value can be determined by checking whether it is a subtype of `stirng` with `extends`, as shown in the example.

If you want to define the tuple of arguments outside the function, write as follows.

```typescript
const beforeList: [number, string, number] = [1, 'a', 1];
const afterList = convert(beforeList);
```

## When the array elements are of generic type

By applying the above example a little more, we can take a Tuple of a generic type as an argument and type it into a function that returns a Tuple of another generic type while keeping the type variable inherited. I have written about this in the following article, which I also posted at the beginning of this article, so I will just write the result.

https://qiita.com/yokotani/items/2ce52e2f47dbd892c591

```typescript
// Define the Before<T> and After<T> types as samples
type Before<T> = {
    type: 'before',
    value: T,
}

type After<T> = {
    type: 'after',
    value: T,
}

// Type definition of convert (implementation of the function body is omitted)
function convert<T extends ReadonlyArray<Before<unknown>>>(beforeList: [...T]): [
    ...{ [K in keyof T]: T[K] extends Before<infer U> ? After<U> : never }
]

// Test
const before1: Before<number> = {
    type: 'before',
    value: 1,
}

const before2: Before<string> = {
    type: 'before',
    value: 'string',
}

const afterList = convert([before1, before2]); // This is of type [After<number>, After<string>].
```

Although there are restrictions on what can be defined with the Tuple type, some JS libraries provide functions that create an array of other objects from an array of objects, so I think this method may be useful in situations where you need to define types for such functions.


Articles

Create an input component that combines React Hook Form with MUI, react-number-format

Passing parameters to the Component generated by the NgComponentOutlet

Dynamic Environment Variables in Angular

Generating sitemap.xml with i18n support in Next.js

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

Type-defining a function that takes an array as an argument and returns an array by TypeScript