TypeScriptでコードを書く時に意識していることを読んだ
自分も普段 TypeScript を使っているので、こういう Tips 的なものはどんどん取り入れていきたい。
型を先に定義する
- 推論させるより自分で書く
- 型 = 設計図という概念
- 先に自分が作るものの設計図を書いてから
- まあこれは分かるが、さすがに毎度
const hoge: string = 'hoge'みたいなところまでやるわけではないよねという認識
定数はリテラル型を先に定義する
- これは以前から考えている「型が先、値は後」の話に近そう
- 値から用意して型を出すのではなく、型を用意してそこから値を出すというやつ
- ただまあ8/1に書いたメモみたいなパターンもあるし、全部が全部これというよりは一部例外もあるよみたいな感じかな
戻り値の型を書く
- API を叩いたときの戻り値とかは基本推論されないので自分で書くことが多いよね、たぶんそれとは別の話
-
戻り値の方を書くことでコードが何を返すのが非常に明確になりますし、関数をリファクタリングする場合にも、意図しない変更を型によって防いでくれる可能性があります。TDDではないですが、戻り値の型を最初に書いてから中のコードを書くことで、意図した戻り値になっていることを（型上は）検証しながらコードを書くことが可能です。
- 戻り値の型名を ${関数}ReturnType にして引数の型名を ${関数}Payload にするというルールを設けるのもよさそう
- 型名の命名規則をある程度決めておくのはよさそう？今までやったことないのでどういう感じになるんだろう
- たとえば関数の戻り値の型が
Articleだったときに毎度type FuncReturnType = Articleとやるか？と言われるとやらない気もする type FuncReturnType = { article: Article }とかなら分かる- あと ReturnType は TypeScript に
ReturnType<T>があるからもしかしたら別の名前のほうが間違えなくていいかもなとも思った
Partial を使わない
- まあ言いたいことは分かる
- が、これもまあ使い方というか、記事にも便利なものは便利なのでこういうときに使うといいよということも書いてある
- Store の型定義を Partial で行うのはよくなさそうというのも分かるので、大元の型定義は Partial を使わず、その型を定義した値などをいじる処理に Partial を使ったら便利そうみたいなイメージがなんとなくある
不要な Optional を避ける
T | undefinedの定義はよくやるけど最適解が未だにわからずその場その場でやっている- Optional と undefined は勿論違うものだけど、どの状況でどちらを使うのがいいのか
- key はあるけど値がないときは undefined で key ごとないときは Optional という感じなんだろうけど
- 悩ましいっすね
children に名前をつける
- 今までの慣習的に children でわかりそうな気もするけど、たしかに明示的に名前をつけたほうがわかりやすいような気もする
- children は基本的にコンポーネントの子に対してつける以外で使われないような気もするので children でも分かるといえば分かる
利用できる型を明示する
- ここはどうなんだろう、今まで通ってきてなさすぎる道なので分からない
React.ComponentProps<T>でよさそうな気もするが、これってもしかして YAGNI ってやつ？