つくる - フック化完了
画面のファイルから、通信と入力を追い出す
第4章の締めくくりです。新しいことは出てきません。ここまでの4つを使って、App.tsx を「見た目を組み立てるだけのファイル」にします。
- useItems に取得をまとめる
- useForm に入力をまとめる
- フックのルールを守る
- 戻り値に型を付ける
送信もフックの仕事にする
いまの App.tsx は、一覧の取得は useItems に任せているのに、出品の POST だけ自分で fetch を呼んでいます。これでは商品データを触る場所が2つに分かれたままです。同じデータを扱う処理は、同じフックに集めます。
TypeScript (JSX)
export type UseItemsResult = {
items: Item[];
loading: boolean;
error: string | null;
addItem: (input: NewItem) => Promise<void>;
};addItem の型は「NewItem を受け取って、終わったことだけを知らせる関数」という意味です。返す約束をしていないので、使う側は結果ではなく完了だけを待ちます。
送ったあとに、なぜ画面が変わるのか
addItem の中では、POST の返事を items の末尾に足します。
TypeScript (JSX)
const made: Item = await res.json();
setItems((prev) => [...prev, made]);サーバーが決めた id 付きの1件が返ってくるので、それをそのまま state に足します。state を書き換えるのはフックの中だけになり、App.tsx には setItems が1つも出てきません。
App.tsx に残るもの
残るのは、フックを呼ぶ2行と JSX だけです。
TypeScript (JSX)
const { items, loading, error, addItem } = useItems("");
const { values, handleChange, reset } = useForm({ title: "", price: "" });ここまで来ると、ロジックの層と見た目の層が分かれます。第5章から先で状態の共有や画面の分割をしても、この2つのフックはほとんど書き換えずに済みます。
演習
addItem と useForm を仕上げ、App.tsx から fetch と入力欄の state を無くします。