なぜカスタムフックか

一覧が2つになった日

第3章までで、商品一覧を API から取ってきて、読み込み中の表示とエラーの表示まで面倒を見られるようになりました。ここで fleama に「トップスの一覧」が増えます。やることはくつの一覧とまったく同じなので、書いたコードをもう1つの画面へ写します。

同じ待ち方は、お知らせを取得するときにも使えます。useEffect の中に async 関数を置き、その中で2回待ちます。

async function loadMessages() {
  const response = await fetch("/api/messages");
  const messages = await response.json();
  setMessages(messages);
}
loadMessages();

商品一覧でも同じ2回の await を使います。くつとトップスでは取得先だけが変わり、取得後の state 更新は同じです。演習のひな形で、2つの一覧を見比べてみましょう。

重複が高くつくのは、直すとき

写すのは一瞬です。高くつくのはそのあとに来ます。

• 失敗したときの再試行を足したい。2か所とも直す
• 取得中に別のカテゴリへ切り替えたときの競合を潰したい。2か所とも直す
• 片方だけ直して、もう片方を忘れる。画面によって挙動が違うという、いちばん見つけにくい不具合になる

同じロジックが n 個あると、直す手間が n 倍になり、直し忘れる確率も n 倍になります。 商品の一覧、カートの中身、購入履歴と画面が増えるほど、この n は増えていきます。

コンポーネントでは切り出せない

React入門では「同じ見た目が2か所にあるならコンポーネントにする」と習いました。しかし今回そっくりなのは見た目ではありません。state と useEffect の組み合わせ、つまりロジックのほうです。見た目は一覧とカードで別々にしたいこともあります。

見た目を持たず、ロジックだけを持ち出す入れ物。それがカスタムフックです。次のレッスンで実際に作ります。この回では取得と state 更新の重複を自分の手で作って、何が二重になるのかを目で確かめておきます。

演習

トップスの取得処理を、くつと同じ async/await の書き方で足します。画面を描く部分は準備済みです。