
## 概要

画面表示の速度を10倍にした際の振り返り

## 背景

サービスの成長に伴いクライアントが増えてきて、データ量も倍々で増えてきており、ある画面の表示速度がかなり遅くなっていた。

ローディング中のまま一向に必要な要素が表示されないという状況。

それにより作業効率が低下しており、課題として顕在化していた。

表示速度はデータ量によってばらつきがあるが、30秒ほど時間がかかっているケースもあった。

## 原因調査

そもそも該当画面でGraphQLのクエリが叩かれまくっていたのとN+1が起きていたので、他のエンジニアがN+1を修正していたが、それでもまだ遅かった。

コードを確認すると、画面表示するために必要なデータを全部取ってくるまでローディングをしていることが分かった。

画面構成要素の一部であるセレクトボックスの選択肢に表示するデータを全件取得しようとしていた。

下記のように`Promise.all`を使っているので、`Promise`が全解決するまでずっとローディング中のままになっていた。

```js
Promise.all([promise1, promise2, promise3]).then((val) => { ... })
```

しかも、ページネーション等も存在しておらず、全てのデータをセレクトボックスの数だけ持ってきてたので、データ量が増えればその分遅くなるという構造になっていた。

## 方針

上述の課題を解決するために下記の方針を立てた。

- 初回の画面表示は行いつつ、セレクトボックス側が描画されたタイミングでレコードを取得する
- 全件取得を避けるためにページネーションを用意

つまり、セレクトボックスの選択肢に必要なレコードは初回描画時に遅延ローディングする。

セレクトボックスごとにレコードを取得することで、APIリクエストを並列化させて全体のリードタイムを抑えつつ、ページネーションを用意して初回取得上限を設ける。

これによりセレクトボックスの選択肢が揃うまで、他の要素の設定（テキストボックス入力など）をしておける状態に持っていける。

&nbsp;

また、特定件数だけ取得して残りはページネーションを用意することで、大量にレコード取得してGraphQLのクエリが何回も発行されることを避けるようにする。（元々全件取得するために無限ローディングしていた）

まとめると、遅延ローディング + デマンドフェッチ。

上記方針で改善を進めていった。

## やったこと

- 描画時にレコードを取得して選択肢を格納するセレクトボックスコンポーネントの作成
  - 以下、遅延ローディングコンポーネント
- セレクトボックスでページネーションを導入
- `Promise.all`を剥がす
- GraphQLを用いた各種APIリクエストの調整

基本的にはセレクトボックスを新規作成して、`Promise.all`を剥がしていった。

### 遅延ローディングコンポーネントの作成

#### ライブラリのバージョンアップグレード

セレクトボックスのコンポーネントは [react-select](https://react-select.com/home) を使っていた。

`react-select`のセレクトボックスを使って遅延ローディングするには、`Async`のpropsを利用する必要があるようだったので、ライブラリのバージョンをアップグレードした。

その上で遅延ローディングのコンポーネントを作成してみたが、関数が発火せずレコードが取得できず調査が難航した。

#### OSSのコードを引っこ抜いて自前で実装

上述した通りうまく作成できなかったので、他のライブラリで実現できないかを調査した。

調査したところ、[react-select-async-pagenate](https://www.npmjs.com/package/react-select-async-paginate)が利用できそうだった。

しかし、リリースノートやタグが切られておらず、破壊的な変更がサイレントで入ってくるリスクがあったので採用できず。

そのため、同ライブラリのコードの中身を引っ張ってきて自前で実装する決断をした。

&nbsp;

https://github.com/vtaits/react-select-async-paginate/blob/52f2e2f0fe99f57bb8536b202ecda409a558b9a5/src/index.jsx

上述のURLは同ライブラリの遅延ローディングの部分であり、クラスコンポーネントで実装されている。

それを関数コンポーネントに直しつつ微調整していった。

最初は難しいかもなと思っていたが、そんなに難しいことはなく初回描画時にAPIリクエストして、stateに詰めているだけなので思ったより簡単。

#### ページネーションを実装

上述したコンポーネントを作成後、そのコンポーネントにページネーションの仕組みを導入した。

リストを最後までスクロールするとGraphQLクエリを発行して次ページを取得するようにした。

加えて、入力値を用いてリスト検索した場合、GraphQLクエリを発行して取得するように実装した。

これにより、無限ローディングを剥がして、デマンドフェッチの仕組みを実装した。

#### 余談

本アプリケーションのフロントエンドはリポジトリパターンで構築されている。

画面描画時の親コンポーネントで必要なデータを取得するために、リポジトリ層を呼び出してレコードを取得している。（ユースケース層を呼び出した方が良いと思うが）

それによって、親コンポーネントのimportがどんどん増えていき、ファイル行数がかなり多くなっており、見通しが悪い状態。700くらいだった。

それが気持ち悪かったので、それを解消するためにレコードを一覧取得する関数だけまとめたファイルを作成して、それをimportする形に変更した。

150くらいファイル行数が減っただけでなく、データ取得の責務をそちらのファイルに分割できた。（神クラスみたいにならないよう運用する際の注意が必要。）

### 小さくデプロイ

コンポーネント自体が完了した後、既存のセレクトボックスを徐々に書き換えるために小さくデプロイをし続けた。

影響範囲を小さく保ち不具合を起こさないようにするため。

全部で20回くらいデプロイしたが、不具合を起こしたのは1回だけだった。（0に抑えたかったが）

### フロントエンドのコンテナがメモリ不足で落ちる問題を解消

開発時にメモリ不足でコンテナが落ちまくっており、~~流石に腹が立って~~ 改善チャンスだったので対応した。

10行くらいファイルを変更して反映を待っていたら、コンテナが`heap out of memory`で毎回落ちていた。

どうやらwebpackがホットリロード時に変更対象ファイルを検知してメモリに載せすぎていたよう。`node_modules`まで検知しようとしていた。

また、webpackのビルド結果をキャッシュするように設定を追加した。

この変更により問題がかなり解消された。

## 結果

レコード数によってまちまちだったが、遅い企業様で画面表示されるまで約25秒かかっていたところを、約1-2秒までに短縮した。

1-2秒は全企業様で固定値だったので、かなり改善できた。

## 開発リードタイムを早めるためにできたこと

- 最初からOSSのコードを参考にする
- コンテナ落ちる問題を早めに対処しておくべきだった
- レビュー会の実施

### 最初からOSSのコードを参考にする

最初は、海外のエンジニアがブログ等に載せているコードを参考に検証を進めていたが、うまく動かなかった。

OSSコードを参考にして検証した方がより確実に動くし早かった。

OSSへの敷居の高さみたいなものを感じていたのと、おそらく自身が読み解くのに面倒さを感じてしまっていた。

カジュアルな内容をもとに簡単に実装できたら良いなという願望のもとに動いていた気がする。

検証段階こそ正確な情報を参照すべきだと痛感した。

### コンテナ落ちる問題を早めに対処しておくべきだった

開発時間の1/4はコンテナ再起動に使っていたかも。

最初は原因がわからずに後回しにしていたが、早い段階から着手しておけばよかった。

本筋以外だとどうしても優先度が下がってしまいがちだが、そこの時間を測ってインパクトを定量化しておくべき。

### レビュー会の実施

20回もデプロイするくらいなのでPR数も多くなっていた。

レビューリードタイムを削減するために、周りを適切に巻き込む必要があった。

ある程度の規模の開発をレビューするとなると、口頭で確認しあうタイミングを設けないとリードタイム削減はしにくいなと感じた。

コンテキストを埋めるのが難しいだけでなく、そこに思考コストがかかるので後回しになりがち。

## まとめ

パフォーマンス改善のタスクってかなり達成感があるのでやっぱり好きだなと感じた。

ただ、この開発を通じて改善点を見つけられたので、今後に活かしていきたい。


画面表示速度を約10倍にした話


## 概要

[type-challenges](https://github.com/type-challenges/type-challenges) というTS文法の練習問題リポジトリがある。

興味本位で解いてみたら楽しくなってきてeasyレベルからmediumレベルまで81問解いてしまった。

その際にTSについての学びが色々あったので共有する。

## 学び一覧

- mapped types
- conditional types
- infer
- minus operator
- union distribution
- never
- template literal types
- length property
- index(numeric) signature
- bottom type

### mapped types

公式doc: [https://www.typescriptlang.org/docs/handbook/2/mapped-types.html](https://www.typescriptlang.org/docs/handbook/2/mapped-types.html)
型引数が主にユニオン型orオブジェクトの場合に利用することが多い。型引数をイテレーションして結果出力する。

```typescript
type MappedTypes<T extends object> = { [P in keyof T]: T[P] };
type s = MappedTypes<{ key: 'test'; value: 'test' }>;
// type s = {
//   key: 'test';
//   value: 'test';
// }

type MappedTypes2<T extends string> = { [P in T]: string };
type t = MappedTypes2<'test' | 'tt'>;
// type t = {
//   test: string;
//   tt: string;
// }
```

### conditional types

公式doc: [https://www.typescriptlang.org/docs/handbook/2/conditional-types.html](https://www.typescriptlang.org/docs/handbook/2/conditional-types.html)
型の条件分岐を実現する。

```typescript
TypeA extends TypeB ? true : false
```

公式docによるとこの条件はextendsの左の型が右の型に代入可能かどうかを判定している。

> When the type on the left of the extends is assignable to the one on the right, then you’ll get the type in the first branch (the “true” branch); otherwise you’ll get the type in the latter branch (the “false” branch).

そのためこれはもちろんfalse

```typescript
type test = string extends number ? true : false;
// => false
```

こちらは原則から考えてtrueになる。

```typescript
type test = 't' extends string ? true : false;
// => true
```

bottom typeの節でneverやundefinedをconditional typesで比較検証する。

### infer

[公式doc](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#type-inference-in-conditional-types)
型を割り出してその後利用できる。

conditional typesとセットで利用する。

例えば、type-challengesの[Last of Array](https://github.com/type-challenges/type-challenges/blob/main/questions/00015-medium-last/README.md) の問題では下記のように解ける。

型引数Tをconditional typesで分岐させ、その中でinferを利用して推論した変数L（配列の最後の要素）を利用する。

```typescript
type Last<T extends any[]> = T extends [...infer _, infer L] ? L : never;
type s = Last<[]>;
// => never

type t = Last<[1, 2, 3]>;
// => 3
```

### minus operator

[公式doc](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#improved-control-over-mapped-type-modifiers)
mapped types内のreadonlyや?を削除するための修飾子例えば、type-challengesの[Mutable](https://github.com/type-challenges/type-challenges/blob/main/questions/02793-medium-mutable/README.md) の問題では下記のように解ける。

```typescript
type Mutable<T> = {
  -readonly [K in keyof T]: T[K];
};

type s = Mutable<{ readonly test: 1 }>;
// type s = {
//   test: 1;
// }
```

### union distribution

**conditional types**や**mapped types**にunion型を渡すと1つずつ処理される。

conditional typesでは条件の左部分が型変数である場合にunion型が分配される。

```typescript
type Equal<U> = U extends 1 ? U : never;
type s = Equal<1 | 2>;
// type s = 1
```

例のコードでは型変数Uにunion型が渡っており1だけを返す。つまり下記が行われている。

```typescript
type TypeA = (1 extends 1) ? U : never
type TypeB = (2 extends 1) ? U : never
```

mapped typesでは以下のような形の場合にunion distributionが発生する。

```typescript
{ [P in keyof T]: X}
```

```typescript
type Distribution<T> = { [P in keyof T]: T[P] };
type val = Distribution<{ foo: string } | { bar: number }>;
// type val = Distribution<{
//    foo: string;
// }> | Distribution<{
//    bar: number;
// }>
```

### never

[サバイバルTypeScript](https://typescriptbook.jp/reference/statements/never)より

> TypeScriptのneverは「値を持たない」型。
> 1️⃣特性1: neverへは何も代入できない
> 2️⃣特性2: neverは何にでも代入できる
> 💥常に例外を起こす関数の戻り値に使える

[TypeScript Deep Dive](https://typescript-jp.gitbook.io/deep-dive/type-system/never)より

> プログラミング言語の設計には、bottom型の概念があります。
> それは、データフロー解析を行うと現れるものです。
> TypeScriptはデータフロー解析(😎)を実行するので、決して起こりえないようなものを確実に表現する必要があります。
> never型は、このbottom型を表すためにTypeScriptで使用されます。

[Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%BC%E3%82%BF%E3%83%95%E3%83%AD%E3%83%BC%E8%A7%A3%E6%9E%90) より

> データフロー解析（英: Data-flow analysis）は、プログラム内の様々な位置で、取りうる値の集合に関する情報を収集する技法である。

制御フローグラフ (CFG)を使って変数の値が伝播するかどうかなどの情報を集め、利用する。

このようにして集められた情報はコンパイラが最適化に利用する。

データフロー解析の基本は到達定義 (reaching definition) である。

### template literal types

JSのテンプレートリテラルを使って展開した値をそのまま型として定義できる。

```typescript
type Join<T extends string, U extends string> = `${T}-${U}`;
type joinedStr = Join<'foo', 'bar'>;
// type joinedStr = "foo-bar"
```

conditional types + inferを利用していこんな風にも書ける。

```typescript
type TemplateLiteral<T extends string> = T extends `${infer F}${infer _L}`
  ? F
  : never;
type str = TemplateLiteral<'foo'>;
// type str = "f"
```

type-challengesで文字列操作するときに初めて知って表現力に驚いたな。

### length property

配列やタプルの要素数をカウントして返す

```typescript
type val = [1, 3]['length'];
// type val = 2
```

Arrayのinterfaceにlengthプロパティが存在する。

```typescript
interface Array<T> {
  /**
   * Gets or sets the length of the array. This is a number one higher than the highest index in the array.
   */
  length: number;
}
```

[https://github.com/microsoft/TypeScript/blob/main/lib/lib.es5.d.ts#L1220-L1402](https://github.com/microsoft/TypeScript/blob/main/lib/lib.es5.d.ts#L1220-L1402)

### index (numeric) signature

配列(orタプル)TにおいてT[number]がunion型で返ることから知った
[公式doc](https://www.typescriptlang.org/docs/handbook/2/conditional-types.html) にも記載ある。

[stackoverflow](https://stackoverflow.com/a/59188070) の記事では、Arrayは下記のようなinterfaceになっていて numberを使ってindexをまとめて取得できるよう。

[https://github.com/microsoft/TypeScript/blob/main/lib/lib.es5.d.ts#L388-L392](https://github.com/microsoft/TypeScript/blob/main/lib/lib.es5.d.ts#L388-L392)
かな？

### bottom type

neverは値を持たないということを表す型でありbottom型とも呼ばれる。集合論で表すと空集合。

never型には何も代入できない（値持たないから）が、never型は他の型に代入できる。

他の全ての型のサブタイプ（部分型）となる。

is-aの関係。逆はできない（他の型をnever型に代入）

```typescript
let neverVal: never = 1 as never;
// never 型は bottom type なのでstring型に代入可能

let str: string = neverVal;
```

ちなみにunkhownは全ての型のスーパータイプなのでどんな型でも代入可能

```typescript
let str = 'str';

// unkhown 型は super type なのでstring型を代入可能
let neverVal: unknown = str;
```

[TS型の階層性](https://zenn.dev/estra/articles/typescript-type-set-hierarchy#%E5%9E%8B%E3%81%AE%E9%9A%8E%E5%B1%A4%E6%80%A7) に詳しく説明がある。

## 今後知りたいこと

- type widening
- homomorphic mapped types
- union distributionをキャンセルする
- etc...

## まとめ

[type-challenges](https://github.com/type-challenges/type-challenges) でTSの型プログラミングにどっぷりハマった。

また再帰的に解く問題が多かったので自然と再帰的に考えられたのもとても良かった。

この経験を通じてTSが好きになったのでもっと深掘りたいと思えたのは大きな収穫。


<書評> type-challengesでeasyからmediumまで81問解いて学んだTSの型プログラミング


## 要約

TSの基礎的な内容が割と網羅されている印象。
抜けていた基礎知識を補えたのが良かった。

## 1章

TSバージョンの年表が面白かった印象。
TS 4.1から応用性の高いtemplate literal typesが導入されてお祭り騒ぎになったらしい。元[PR]("https://github.com/microsoft/TypeScript/pull/40336")はこちら。
template literal typesってinferと組み合わせると有用だなと思ったり。

あとはenum使わない方が良いみたいなのは知らなかった。JSには存在しない独自機能だからとのこと。

[LINE社の記事]("https://engineering.linecorp.com/ja/blog/typescript-enum-tree-shaking/")を見ると、
JSに存在しないenumを表現するためにIIFE(即時実行関数)を含んだコードをトランスパイルするらしい。それがバンドルされてしまうからtree-shakingできなくなるよとのこと。なるほど。

## 2章

値がない状況を表すのにundefinedの方が推奨されるとのこと。

[MicrosoftのTSコーディング規約]("https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines#null-and-undefined")にも **Use undefined. Do not use null.
**の記載がある。

[サバイバルTypeScript]("https://typescriptbook.jp/reference/values-types-variables/undefined-vs-null")にはこのような記述がある

- undefinedは「値が代入されていないため、値がない」nullは「代入すべき値が存在しないため、値がない」
- nullは自然発生しない
- undefinedは変数
- undefinedはtypeofの結果がプリミティブ名を表す\"undefined\"になるのに対し、nullは\"null\"ではなく\"object\"になります。

最後のは割とびっくりする挙動。言語仕様的にundefinedが自然発生してくれるのでそれに合わせにいくのが良さそう。

ただ外部APIとのやり取りでnullが渡ってくるのはあると思うので、そこの考慮が必要そう。

[Null 合体演算子 (??)&nbsp;]("https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Nullish_coalescing_operator") と [論理 OR 演算子 (||)&nbsp;]("https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_OR") の違いを知った。 **||** はnullやundefinedだけでなく空文字や0、falseなども \"ない\"と評価して右辺値を返すが、**??** はnull orundefinedの場合のみ右辺値を返す。


ES2021の新機能として [||=(論理和代入)]("https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_OR_assignment")[ \*\*\*\*]("https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_OR_assignment")や[**&&=**]("https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_AND_assignment")[(論理積代入)]("https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_AND_assignment")演算子もある。

論理和代入はrubyの自己代入演算子と同じ。論理積代入は左辺がtruthyなものの場合に右辺の値を左辺に代入。

## 3章

### スプレッド構文とシャローコピー

スプレッド構文はシャローコピーであること。
下記よりスプレッド構文でコピーしてもネストしたオブジェクトは同じアドレスを共有している。

```typescript
const object = { name: 'test', type: { a: 'a' } };
const anotherObject = { ...object };
object.name = 'object';
anotherObject.type.a = 'b';

console.log('object', object);
// object { name: 'object', type: {a: 'b'} }
console.log('anotherObject', anotherObject);
// anotherObject { name: 'test', type: {a: 'b'} }
```

[ディープコピーをする方法]("https://developer.mozilla.org/ja/docs/Glossary/Deep_copy")の1つとして、**JSON.stringify()** でオブジェクトを JSON 文字列に変換し、
**JSON.parse()** で文字列から（完全に新しい） Javascript のオブジェクトに変換する方法がある。
また、ネストしたオブジェクトもスプレッド構文で展開する等々。

### インデックスシグネチャについて

[インデックスシグネチャ]("https://typescript-jp.gitbook.io/deep-dive/type-system/index-signatures")は型安全性を破壊する。
オブジェクトのkeyがstringの場合、obj.key でアクセスできるが、obj.foo /
obj.aなど任意のkeyにもアクセスできてコンパイルエラーにならないので型安全ではない。

```typescript
type Obj = { [key: string]: number };
const obj: Obj = { foo: 1 };

console.log(obj.t);
// => コンパイルエラーにならない
```

### 部分型関係について

型Sが型Tの部分型であるとは、S型の値がT型の値でもあることを指す。
下記の例ではFooBarBaz がFooBar
の部分型である。
FooBarBazはFooBarの要素を全て持つ。FooBarBaz型であればFooBar型でもあるということ。

```typescript
type FooBar = { foo: string; bar: number };
type FooBarBaz = { foo: string; bar: number; baz: boolean };
const obj: FooBarBaz = { foo: 'hi', bar: 1, baz: false };

console.log('obj', obj);
// "obj",{"foo":"hi","bar":1,"baz":false}

const obj2: FooBar = obj;
console.log('obj2', obj2);
// "obj2",{"foo":"hi","bar":1,"baz":false}
```

### タプル型

要素数が固定された配列型。
要素数が固定されている代わりに、それぞれの要素に異なる型を与えられる。

### オブジェクトの分割代入（destructuring assignment）について

型注釈つけられないで型推論していく

### プリミティブのプロパティ

文字列や数値などのプリミティブ型は、プロパティを持ったオブジェクトとして扱える。

プリミティブ型をまるでobjectのように扱えるのはJSの特徴。JSには、プリミティブ型をオブジェクトに自動変換するオートボクシングと呼ばれる機能がある。参考:
https://typescriptbook.jp/reference/values-types-variables/primitive-types

```typescript
'name'.length; // 4
```

## 4章

### contextual typing

逆方向の方推論のことで、型が事前に分かっている場合の推論。
通常の型推論は型注釈は無いけれど値から型を推論できる場合に発動

```typescript
const xRepeat = (arg: number): string => 'x'.repeat(arg);
// xRepeatの型が自動的にconst xRepeat: (arg: number) => string と判定される
```

逆方向の型推論は型を事前に割り当てているから式中の型を省略できる。

```typescript
type F = (arg: number) => string;
const xRepeat: F = (arg) => 'x'.repeat(arg);
// (arg: number): string の指定は不要
```

コールバック関数なども指揮中で引数の型を書かない場合が多い。
例えばfilterなどはレシーバを元に型引数が決まる。

```typescript
const nums = [1, 2, 3];
const ary = nums.filter((x) => x > 2);
// 式中xの変数をnumberとしなくても x>2 でコンパイルエラーが起きない
// (value: number) => unkhown
```

## 5章

protectedはクラス自身だけでなく子クラスからもアクセス可能。rubyと同じだな。

### プライベートプロパティについて

\#プロパティ名 と private修飾子をつけたもの両方で表現可能。

- privateはTS独自機能なのでトランスパイル後のランタイム上では普通のプロパティとして扱う。
- \#プロパティ名はJSの機能なのでランタイム上でもプライベート性が担保される

### this

thisはプロパティを参照することが多く、そのプロパティがundefinedであった場合にランタイムエラーが発生する可能性あり。

- アロー関数は外側のthisを引き継ぐ
- 普通の関数は呼び出し時のレシーバをthisとする

アロー関数への書き換えをするリファクタリングを業務で行ったなあ。

## 6章

### インターセクション型

T型でありかつU型でもある値を意味する型
参考: https://typescriptbook.jp/reference/values-types-variables/intersection
ちなみに string
& numberのプリミティブのインターセクション型は存在しないのでnever返る

### [Optional chaining]("https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Optional_chaining")

レシーバに対する参照が nullish (null または undefined) の場合にエラーとなるのではなく、式が短絡され undefined
が返される。
?.はそれ以降のプロパティアクセス・関数呼び出し・メソッド呼び出しをまとめて飛ばす効果を持つ。

```typescript
const adventurer = { name: 'Alice', cat: { name: 'Dinah' } };
const dogName = adventurer.dog?.name.t;
console.log(dogName);
// expected output: undefined
// dogが存在しないのでそれ以降の .name.t は評価されずにundefinedが返る
```

### リテラル型のwidening

リテラルが自動的に対応するプリミティブ型に変化する（広げられる）特徴。

constの場合はリテラル型なのにletの場合はプリミティブ型に変化している。

letは再代入が期待されるのでプリミティブ型に変化する。

ちなみにconstで宣言したオブジェクトリテラルも再代入可能なのでwideningされる。

```typescript
const test1 = 'test';
// const test1: "test"

let test2 = 'test';
// let test2: string

const test = { a: 'a', b: 1 };
// const test: { a: string; b: number; }
```

wideningを防ぎたい場合は、リテラル型を含む型注釈をつけるか as constを利用して宣言する。

### ユニオン型

型の絞り込みに対応している点が素晴らしいとのこと。なるほど、そういう解釈ができるのか。

関数の引数をユニオン型で取って、式中で型の分岐を行つつ処理をしていけるということに価値があるのか。

### lookup型

**T[K]** のようにオブジェクトプロパティにアクセスする際の型

### as const

asを使った型アサーションは型安全性を破壊しかねないけれど、as constはそれとは異なる。

1.  配列リテラルの型推論結果を配列型ではなくタプル型にする
2.  オブジェクトリテラルから推論されるオブジェクト型は全てreadonlyになる（配列リテラルも）
3.  プリミティブのリテラル型がwideningしない
4.  テンプレート文字列リテラルの方がstringではなくテンプレートリテラル型になる

```typescript
// readonly
const names = ['taro', 'jiro'] as const;
// const names: readonly ["taro", "jiro"]

const obj = { name: 'test', address: { city: 'xxxx' } } as const;
// const obj: {
//  readonly name: "test";
//  readonly address: {
//    readonly city: "xxxx";
//  };
// }
// wideningされない

const name1 = 'name' as const;
let name2 = name1;
let name2: 'name';
// let name2: "name"

let name3 = 'name3';
// let name3: string
// templateliteral type

const n: number = 1;
const value = `${n}px` as const;
// const value: `${number}px`
```

### any型とunkhown型

- any型
  - 型チェックを無効化する型。基本的に何でも代入可能なのでコンパイルエラーにならない。
  - JSからTSへの移行を支援するためや、型をうまく表現できないためのエスケープハッチとしての存在理由あり
  - anyよりasやユーザー定義型ガードの利用を検討した方が良い
- unkhown型
  - なんでも入れられる型。何かは入っているが何かは分からないような状況を表す
  - anyはコンパイルエラーにならないので、val.nameなどにアクセスできるがunkhownはできない。TSコンパイラがunkhownは値がないことを読み取ってできることを制限してくれる。

### **never型**

値を持たないことを表す型
never型には何も代入できない。（never型にnever型は代入可能）

他の型にnever型は代入できる。そのため、[TSではbottom型と呼ばれている]("https://typescript-jp.gitbook.io/deep-dive/type-system/never")。（[取りうる値の集合が一番大きい]("https://ja.wikipedia.org/wiki/%E3%83%9C%E3%83%88%E3%83%A0%E5%9E%8B#:~:text=%E3%83%9C%E3%83%88%E3%83%A0%E5%9E%8B%EF%BC%88%E3%83%9C%E3%83%88%E3%83%A0%E3%81%8C%E3%81%9F,%E3%81%84%E3%81%8B%E3%81%AA%E3%82%8B%E5%80%A4%E3%82%82%E8%BF%94%E3%81%95%E3%81%AA%E3%81%84%E3%80%82") => ボトム型は全ての型の部分型）

#### [voidとneverの違い]("https://typescriptbook.jp/reference/statements/never")

- voidはundefinedを代入できるがneverはできない（値を持たないから）
- どちらも戻り値がないことは同じ
  - voidは関数がreturnされるか、最後まで実行されることを表す
  - neverは中断されるか永遠に実行される

### **ユーザー定義型ガード**

型の絞り込みの一種
**引数名 is 型名** という形で引数を型名で絞り込んで処理する。
下記の関数は戻り値がbooleanであり、trueならば引数がstring or
numberであるということを意味する。

```typescript
function isStringOrNumber(value: unknown): value is string | number {
  return typeof value === 'string' || typeof value === 'number';
}

function useUnknown(v: unknown) {
  // v はここでは unknown 型
  if (isStringOrNumber(v)) {
    // v はここでは string | number 型
    console.log(v.toString());
  }
}
```

参考: [https://blog.uhy.ooo/entry/2021-04-09/typescript-is-any-as/]("https://blog.uhy.ooo/entry/2021-04-09/typescript-is-any-as/")
**asserts 引数名 is 型名** という型述語もある。
この場合は戻り値がvoidで「関数が無事に終了すれば引数名は型名である」

### **union distribution**

conditional typesの性質
conditinal typesを利用している型にユニオン型を渡すと分配して処理してくれる
[公式]("https://www.typescriptlang.org/docs/handbook/2/conditional-types.html#distributive-conditional-types") のやつコピペしただけだけどこんな感じになる。

```typescript
type ToArray<Type> = Type extends any ? Type[] : never;

type StrArrOrNumArr = ToArray<string | number>;
//  ToArray<string> | ToArray<number>; と等しいので、string[] | numbe[]が返る
```

## 7章

### commonJS

[nodejsで利用されているソースコードをパッケージ化するモジュール。]("https://nodejs.org/docs/latest/api/modules.html")
最近はECMAScriptのESmodule形式も採用しているよう。
requireを利用してimportする。

```typescript
const circle = require('./circle.js');
console.log(`The area of a circle of radius 4 is ${circle.area(4)}`);
```

## 今後

(本書付録2の更なる学習の道しるべコピペしただけ)

### JS言語機能

- イテレータ・ジェネレータ
- メタプロ系
  - オブジェクトの操作（Object.keys）など
  - プロパティディスクリプタ・プロパティ属性
  - Reflect・Proxy
- シンボル
- prototype

### TSの言語機能

- 標準ライブラリに属する他の型（Record・Parameters・Awaitedなど）
- abstractクラス・abstract new シグネチャ
- 型レベルプログラミング
- mapped types conditionaltypes
  - infer / union distribution / homomophic typesなど


Kdevlog

画面表示速度を約10倍にした話

<書評> type-challengesでeasyからmediumまで81問解いて学んだTSの型プログラミング

<書評> プロを目指す人のためのTypeScript入門安全なコードの書き方から高度な型の使い方まで

Kdevlog

画面表示速度を約10倍にした話

<書評> type-challengesでeasyからmediumまで81問解いて学んだTSの型プログラミング

<書評> プロを目指す人のためのTypeScript入門 安全なコードの書き方から高度な型の使い方まで

<書評> プロを目指す人のためのTypeScript入門安全なコードの書き方から高度な型の使い方まで