【実録Q＆A】型をキメて書くとあと楽ですよ〜な話

はじめに

前回の記事で「エラーを直す前に、何に対して何をしているかを言語化する」と書きました。

今回はその“実践編”として、react-selectで発生したトラブルを例に、「型をキメて型安全に書くと、どれだけ楽になるか」を紹介します。

起きていた問題

「カテゴリー選択のセレクトボックスが正しく表示されない」という相談を受けました。
セレクトボックスちょっと難しいですよね〜。

push済みのPRを共有していただいたので、手元で確認しました。

確認したところ起きている問題は大きく二つ。

• オプション（候補の部分）が表示されない

• 初期表示の選択状態（value）が反映されない

こんな状態でした！ここホントむずいですよね💦

方針

動くようにするのではなく、次は自分で解決できるように私がどうやってデバックしていったかを順序立てて共有するようにしました。
メモ帳に貼ってましたw

詳しく確認する

選択肢が表示されない理由を探る

まず考えたのはオプション値の取得はできている？？です。

API取得するないようなのでネットワークタブで確認しました。

うん、ここは問題ないですね。

ということはカテゴリーのオプションのセットができていないということが明らかになりました。
次はデータはあるのに表示されないので表示されない理由を探すって感じです。

で、渡してるデータの型を見ると問題発見👀

OptionType[]

になっていますが、

type OptionType = { id: string: name: string}

こうなってました！

react-selectの公式ドキュメントには

こうあります。型違いますね！！！

type OptionType = { label: string: value: string}

こうあるべきです。ここ修正したらすんなり表示されました。

一旦ここまでコミット！

（めちゃわかりやすくないですか、、pushできなかったのでフォークしましたw）

次！！！

選択済みにならない理由を探る

selectboxに渡してるデータの型はOptionType[]に一致しているので実際に入ってる値が何が別のものになっている可能性が高そうだと考えました。

じゃあselectboxに渡してるデータの中身を必殺console出力！！

全然違いますね、、！型の不一致が発覚しました！！

問題はレスポンスの型が不明(any)の状態でOptionType[]に突っ込んでることでした。APIレスポンスって

const response = await data.json();

こんなふうにjsonとして扱えるようにパースしますよね？その時点でresponseはany型なんですよね。ここは推論できないので。

なので、このresponseの型はこれだ！って実際に返ってきた値を見て定義する必要があります！！

ということでresponseの型を定義して（今回は分割代入していたのでresponseのcategoriesプロパティだけにしましたが、本来はレスポンス全体の型定義が自然だと思います）、ステートにセットする時はステートの型に合わせるようにして完成！！

できたのでコミット！

今回学べたこと

結局型キメとくと楽ですよってことです！！

1. セレクトボックスの型が違う

2. APIレスポンスがanyでなんでもありになってた

3. ステートの型と代入している値がanyのせいで一致していない

つまり型不一致まつりになっていました。

問題の切り分け

重複しますが、まずは順番に、どこまで正しく動いているかを確認していくことが大事です。

1️⃣ APIレスポンスを確認

　→ データは取れている（Networkタブ、console.logがOK）

2️⃣ ステートの中身を確認

　→ 形が想定と違うanyだから何でもいけてしまって気づけていなかった

3️⃣ react-selectの仕様を確認

　→ { value, label } の配列が必要

伝えたいこと

型は敵じゃない！未来の自分を助けてくれる存在！！

型を整える前は、「値はあるのにエラーなく表示されない」という曖昧な状態。

でも型を決めておくと、エディタが先に「ここ違うよ」と教えてくれます。

• anyを放置すると、後でどこが違うのか分からなくなる

• 型を先に決めておくと、後から考えなくていい

つまり、型はめんどくさい存在ではなく、自分を助けてくれる存在なんです！
型の恩恵を受けてこれに気づくとTS大好きになると思います！！

まとめ

• 「表示されない」「値が入らない」ときは、まず型を疑う（ほんとにその型になってる？？）

• anyをなくして、APIレスポンス・state・UIの型を揃える

• 型をキメておくと、デバッグが圧倒的に楽になる

• TypeScriptの“型安全”は、堅苦しいルールじゃない

おわりに

現場でもスクールでも、型が整っていないコードはトラブルの温床になると思います。
ちゃんと定義しておけばエディターで問題がわかるのに雑にしてしまうとエラー吐かないのに動かないなどの問題があったり、またはだいぶ先でエラー吐くなんてことになっちゃいます。

逆に、型がきちんと定義されているコードは、自然に理解しやすく、ミスも防げるし、補完で書いていけて楽々です！

「型をキメて書く」は、最初は少し面倒に感じても、最終的には自分を楽にする最高の投資だと改めて感じました。伝われ！！！