コンポーネントとAPIの違い｜再利用しやすい設計と連携・テストの進め方

同じような画面を何度も作っている。ボタンを修正したら、別のページの表示まで変わってしまった。APIにつないだ途端、画面が表示されなくなった。開発を進めると、機能を作るだけでなく、変更しやすい構造を考える場面が増えてきます。

コンポーネントは機能や画面をまとめた部品、APIは機能やデータを利用するための窓口です。役割を分け、受け渡す情報を明確にすることで、修正箇所や問題の原因を確認しやすくなります。

この記事では、WebアプリのUIコンポーネントとWeb APIを中心に、分割の考え方、連携の手順、テストのポイントを整理します。学習記録アプリの一覧画面を例に、具体的に考えていきましょう。

１．コンポーネントとAPIは、何が違うのか

コンポーネントは、一定の役割を持つまとまりとして扱う部品です。Web画面なら、検索欄、記録一覧、入力フォームなどを、それぞれの責任に応じて分けて考えます。

APIは、別の処理から機能やデータを利用するためのインターフェースです。外部サービスに限らず、自分たちのフロントエンドとバックエンドをつなぐ場合にも使われます。

例えば、APIが学習記録の一覧を返し、そのデータを一覧コンポーネントが表示する構成が考えられます。ただし、すべてのコンポーネントが個別にAPIを呼び出す必要はありません。

また、APIを利用するだけで通信やデータが安全になるわけではありません。認証、操作権限の確認、入力の検証などは、用途に応じて設計する必要があります。

２．コンポーネントは、役割と変更の理由で分ける

コンポーネントを分ける目的は、ファイル数を増やすことではありません。何を担当する部品なのかを説明でき、変更するときに確認すべき範囲が分かるようにすることが大切です。

学習記録の一覧画面なら、次のような分け方が考えられます。これは設計例であり、どのアプリにも同じ構成が必要という意味ではありません。

行数だけで分割を決めない

「100行を超えたら分割する」といった基準は、チーム内の見直しの目安にはできます。しかし、一定の行数以内であれば良い設計だと判断できるわけではありません。

短いコードでも、予約、決済、会員管理などの異なる判断が混ざっていれば追いにくくなります。反対に、関連の強い処理を細かく切りすぎると、複数のファイルを行き来しなければ流れを理解できなくなります。

見た目が似ているだけで共通化しない

例えば、「記録を保存するボタン」と「アカウントを削除するボタン」は、見た目を共通化できるかもしれません。一方、確認手順や失敗時の対応まで同じにする必要があるとは限りません。

何を共通にし、何を呼び出し元で決めるかを整理しましょう。業務専用のコンポーネントにも役割があり、すべてを汎用部品にする必要はありません。

３．共通化すると、変更の影響も広がる

共通コンポーネントを使うと、複数の画面に同じ修正を反映しやすくなります。その一方で、部品の変更が多くの利用箇所に影響することもあります。

例えば、共通の入力欄に「空欄は許可しない」という処理を追加すると、任意入力だった項目まで送信できなくなる可能性があります。見た目の修正と、入力ルールの変更を分けて考える必要があります。

• どの画面で使われている部品かを確認する。
• 入力値や設定によって変わる動作を整理する。
• 変更した部品だけでなく、代表的な利用画面でも確認する。
• 共通化によって条件分岐が増え続ける場合は、役割を分け直す。

再利用によって重複を減らせても、テストや確認が不要になるわけではありません。共通部分の確認と、各画面での組み合わせの確認を分けて進めましょう。

４．API連携では、受け渡す情報の約束を決める

フロントエンドとバックエンドを分けると、役割ごとに開発を進めやすくなります。ただし、両者が完全に独立して作業できるわけではありません。

項目名やデータ型、エラー時の応答などを合わせていなければ、個別には動いても連携したときに問題が起きます。実装前に、最低限の仕様を共有しましょう。

例えば、学習時間の値が「30」でも、片方が分、もう片方が秒として扱えば、型が数値でも結果は間違います。項目名や型に加えて、単位と意味までそろえることが重要です。

APIの仕様を変更するときは、既存の画面やほかの利用者への影響も確認します。項目の削除や名称変更を行う場合は、対応する順番や移行期間を相談しましょう。

５．連携は、モック・通信・画面の順に確認する

まず、モックデータで画面を作る

モックデータとは、開発やテストのために用意する仮のデータです。APIが完成する前でも、合意した形式のデータがあれば、一覧表示や絞り込みの確認を進められます。

ただし、モックが実際の仕様とずれていれば、接続時に修正が必要になります。正常なデータだけでなく、０件、長い科目名、任意項目が欠けた場合なども用意すると、表示上の課題を見つけやすくなります。

通信の成功と、データの妥当性を分けて確認する

JavaScriptのfetchでは、404や500などのHTTPエラーが返っても、それだけでPromiseが拒否されるわけではありません。通信の例外処理に加え、Response.okやステータスコードを確認する必要があります。

さらに、HTTP上は成功していても、想定した項目がない場合や、JSONとして解析できない場合があります。受け取った値が、画面で利用できる形式かも確認しましょう。

画面には「成功」以外の状態も用意する

「０件」と「取得失敗」を同じ空白画面にすると、利用者は何が起きたか判断できません。保存処理では、成功が確認できる前に「保存しました」と表示しないことも大切です。

６．TypeScriptの型指定と、実行時の検証を区別する

TypeScriptは、開発時にデータの扱いを確認する助けになります。例えば、数値として扱う項目に文字列を渡すなど、型の不一致を検出できる場合があります。

一方、型を指定しただけで、APIから届くデータが自動的に検証されるわけではありません。型注釈は実行時の値をチェックする処理ではないため、外部データには別途確認が必要です。

学習記録なら、記録一覧が配列か、科目名が文字列か、学習時間が仕様に合う整数かなどを確認します。必要に応じて、検証用の関数やスキーマ検証ライブラリを利用します。

なお、画面側の検証は、バックエンド側の入力検証や権限確認の代わりにはなりません。画面を経由せずAPIへ要求が送られる場合も想定し、それぞれの場所で必要な確認を行います。

７．APIの呼び出し回数は、実際の処理を見て改善する

コンポーネントごとに通信処理を置くと、同じデータを重複して取得する場合があります。まずはブラウザの開発者ツールなどで、いつ、どの要求が、何回送られているかを確認しましょう。

同じ一覧を使う複数の部品なら、共通の場所で取得して渡す構成が候補になります。ただし、すべてのデータ取得を一つの親コンポーネントへ集めることが、常に適切とは限りません。

N+1問題と、単なるリクエスト数の多さを区別する

N+1問題は、例えば一覧を１回取得した後、各項目の関連データを取得するために追加でN回問い合わせるようなパターンです。ブラウザからAPIへの通信だけでなく、サーバーからデータベースへの問い合わせでも起こります。

GraphQLを採用しても、自動的に解消されるわけではありません。ブラウザからの通信が１回でも、サーバー内部で項目ごとの問い合わせが繰り返される場合があります。

対策には、関連データをまとめて取得する、重複をまとめる、適切にキャッシュするなどの方法があります。通信回数だけでなく、応答時間、転送量、データベースへの問い合わせも見て、負荷の原因に合う対策を選びましょう。

８．部品単体と、実際の組み合わせを両方テストする

コンポーネント単体で表示できても、APIと接続した画面が正しく動くとは限りません。確認したい内容に合わせて、部品、API、連携した画面をそれぞれ確かめます。

絞り込みを素早く切り替えた場合には、先に送った古い要求の結果が後から届くこともあります。最新の選択と違う一覧が表示されないかなど、実際の操作に近い条件も確認しましょう。

不具合が起きたときは、「画面の操作」「送った要求」「返された応答」「表示結果」を順に調べます。原因を確かめずに共通コンポーネントを変更すると、別の画面まで影響を広げる可能性があります。

設計と連携のチェックリスト

• 各コンポーネントの役割を、短い言葉で説明できるか。
• 共通化した部分と、画面ごとに異なる部分を区別しているか。
• 共通部品を変更したときの利用箇所を確認できるか。
• APIの項目名、型、単位、空の場合、失敗時の応答を決めているか。
• 読み込み中、０件、取得失敗を区別して表示しているか。
• 外部から受け取ったデータを、実行時にも検証しているか。
• 重複した通信やサーバー内部の問い合わせを確認しているか。
• 部品単体と、APIにつないだ操作の両方を確認しているか。

よくある質問

コンポーネントは、必ず複数の画面で使い回すべきですか？

必ずしもそうではありません。１つの画面でしか使わなくても、独立した役割を持ち、表示や操作を確認しやすくするために分ける意味があります。再利用の回数だけで判断せず、責任の分け方も考えましょう。

Reactなどのフレームワークを使えば、設計は自動的に良くなりますか？

フレームワークは部品化や状態管理を支援しますが、どの役割を分けるかは開発者が考えます。まず画面の構成とデータの流れを整理し、選んだ技術の公式ガイドに沿って実装してください。

既存の画面は、一度に作り直した方がよいですか？

現在の課題と変更範囲によって判断します。例えば、同じ入力欄の修正を繰り返しているなら、その部分を共通化する方法が考えられます。変更前後で必要な操作ができることを確かめながら進めましょう。

モックで動作確認できれば、実際のAPIとのテストは不要ですか？

不要にはなりません。実際の通信では、認証、遅延、応答形式の違いなど、モックだけでは確認できない条件があります。モックで画面を確認した後、実際のAPIとの連携も確かめてください。

まとめ：部品の役割と、受け渡す情報を明確にしよう

コンポーネントとAPIを活用するときは、細かく分けることや、新しい技術を増やすことだけを目標にしないようにしましょう。何を担当する部品なのか、どんな情報を受け渡すのか、失敗時にどう動くのかを説明できることが重要です。

まずは１つの一覧画面を選び、表示する部品と取得するデータを整理してみてください。変更の影響を確認しながら、必要な範囲から再利用と連携を進めていきましょう。

参考資料

• React：Thinking in React — UIの分割、データの受け渡し、状態の整理。
• MDN Web Docs：Using the Fetch API — HTTPステータスの確認と応答の扱い。
• TypeScript：The Basics — 型チェックと、実行時には残らない型注釈の説明。
• GraphQL.js：Solving the N+1 Problem with DataLoader — GraphQLでのN+1問題と、取得処理をまとめる考え方。