97. Network タブ — 「画面に出ない」の半分は通信

データが画面に出ないとき、原因の半分はコードではなく通信にあります。DevTools の Network タブを開いてから操作を再現すると、送られたリクエストが時系列で一覧に並びます。まず見るのはステータスコードで、404 はURLの間違い、500 はサーバー側の問題、failed はそもそも到達していないことを示します。

ステータスが 200 でも安心はできません。リクエストを選んで Response タブを見ると、サーバーが実際に返したJSONの中身を確認できます。配列だと思ったらオブジェクトに包まれていた、という食い違いはよくあります。POST なら Payload タブで、自分が送った中身が意図どおりかも点検しましょう。

CORS エラーは初学者を最も混乱させます。コンソールに blocked by CORS policy と赤く出ますが、これはブラウザが応答の受け取りを拒否した状態で、原因はサーバー側の許可設定にあります。Network タブで該当リクエストを選び、応答ヘッダーに Access-Control-Allow-Origin があるかを見るのが本質的な確認方法です。

サンプルコード(フレームワーク環境が必要なため表示のみ)

// Network タブでの調査手順(「一覧が表示されない」場合の例)
//
// 1. DevTools の Network タブを開く → Fetch/XHR で絞り込む
// 2. 画面を操作して現象を再現する(リロードでもよい)
// 3. 一覧に並んだリクエストの Status 列を見る
//
//   Name        Status   意味と次の一手
//   ──────────────────────────────────────────────
//   users       404      URLが違う → コード内のパスを見直す
//   users       500      サーバー側 → サーバーのログを見る
//   users       200      届いている → Response タブで中身を確認
//   users       (failed) 到達していない → サーバー起動/URL/CORS
//
// 4. Status 200 なのに出ない場合:
//    Response タブ … サーバーが返した生のJSONを確認
//      { "data": [...] } ← 配列を直接期待していると食い違う
//    Payload タブ  … POST で自分が送った中身を確認
//
// 5. CORS の見分け方:
//    コンソール: blocked by CORS policy(ブラウザが受け取りを拒否)
//    Network:    応答ヘッダーに Access-Control-Allow-Origin が無い
//    → 直す場所はフロントではなくサーバー側の許可設定

サンプルコードで身につける(5本) →

学んだ概念を、素朴な例から実務寄りの例まで5つの具体例で確認します。

公式ドキュメントで詳しく ↗