【10章】NextJSでのバックエンド開発演習（前半）の振り返り

結論

型注釈や共通コンポーネント化など、指摘を複数いただいた。 でも、本質的な修正は1つだけだった。「同じものを2箇所に書かない」ということだ。

なぜ、私はそのようなミスをしていたのか。 理解していたつもりでも「なんとなくこのような書き方だな」というような書き方をしていたからだ。 そのため、全体を考慮してコードを書くことができていなかった。作成や編集の機能を単体で書けても、アプリというマクロ的な見方ができていなかった。

「なんとなく」が一番の危険信号だった。

この章でやったこと

• TypeScript でフロントエンド / バックエンドの両方を実装

• SQL の学習

• 記事・カテゴリーの CRUD(読込・作成・更新・削除)

1. 新規作成と編集は「別物」ではなかった

分けて書いていたときの判断

まず、ボタンの数が違っていた。

• 新規作成は「作成」の1個

• 編集は「更新」「削除」の2個

ボタンの位置はフォームの下で共通していたし、フォームの数と内容も共通していた。 しかし、作成と編集では異なる API を使用していた。そのため、共通コンポーネントとして考えるということが浮かばなかった。

それまで自分が作った共通コンポーネントは、ヘッダーと admin のサイドバーだけだった。 どちらも常に同じ動きをするもので、場面によって振る舞いを変えるという発想がなかった。 だから、作成と編集のように「動きが違うもの」を共通化するという選択肢自体が浮かばなかった。

これも「なんとなく」のまま書いていた部分だ。

React の props の使い方を理解していなかったのも、理由の一つとして考えられる。

指摘を受けて気づいたこと

なにより、共通化できるんだという衝撃だった。 共通化すれば保守性が上がり、管理もしやすくなることに気がついた。

でも、そのすぐあとに思い浮かんだのは「どうやってやるんだ」だった。

共通化で一番詰まったところ

詰まったのは、どのような値を与える必要があるのかが作成と編集で違ったところだ。 編集には、初期値を API 経由で取得する必要があった。

そもそも props の使い方自体が理解できていなかった。 値の渡し方、props をどこで実装するのか、必要な型は何なのか。調べることから始まった。

ネットで props の使い方について調べ、挙動を確認しながらエラーを改善していった。 また、ShiftB の方のブログを拝見したところ、同じようなところで躓いている方もいたので、そこも参考にさせていただいた。

共通化して変わったこと

• コード量が減って管理しやすくなった

• エラーが出ても原因を特定しやすくなった

直す場所が1箇所に絞られるからだ。

2. 型は境界に置く

同じことは、UI だけでなく型にも起きていた。

フロントとバックエンドで同じ型を使う

データ構造をわざわざ区別して考えるようにしてしまっていた。

フロントとバックエンドが TypeScript という同じ言語で書かれている以上、型は共有できる。 実際には、バックエンド側で定義したレスポンスの型をフロントから import する形にした。

これも「同じものを2箇所に書かない」だ。以前は、同じデータなのにフロント側で別の型を書いていた。それだと、バックエンドの型を変えてもフロント側は気づけない。

useForm に型引数を渡す

はじめは useForm() に型を渡しておらず、handleSubmit に渡す関数の引数の型が緩いままだった。 そこに useForm<FormType>() と型引数を渡すと、handleSubmit の引数が FormType に強制される。

フォームの型を1箇所で決めれば、送信処理まで自動で縛られる。 安心して値をバックエンド側に渡せるようになった。

まとめ

「なんとなく」な部分に自分の課題がある。

フロントエンドとバックエンドのデータの繋がりと整合性が理解でき、より TypeScript の良さを理解することができた。

今後は設計者的な観点を持ち、実装していく中で共通化できそうな部分がないかを判断できるようになっていきたい。