最近のフロントエンド調べる 2025/12/07
色々わからない用語や進化があるのでまとめていく。
Server Components
サーバー側でレンダリングされるらしい。（結果をクライアントに返す）
Next.js が動作している実行環境（Node.jsとか）でレンダリングされる。
React Server Componentとも呼ばれる。
SSR のように「完成した HTML 一枚」を返すわけではない
「RSC Payload」という特殊な JSON ストリームを返す。仕組みを指す言葉でもある。
ストリームってなんじゃい
完成済みの HTML を丸ごと 1 枚返す仕組みではなく、段階的にデータを送り返す仕組み
/emoji/tea.iconなるほどストリーム。連続性ある。
Client Component
バンドルされる
デプロイなどのビルド時に行う
コンポーネントをまとめて、ブラウザで実行できる JavaScript ファイルを作ること。
クライアントで動かすためバンドルされる。
use clientと書くやつ。
SCは呼べない。（それはそう）
整理
Server Componentでデータを作る→RSC Payloadが渡す→Client Componentがそれを表示。
React
React単体ではルーティングやデータ取得、ビルドなどは自分で設定する必要がある
SEOで不利になる話
CSRだと、htmlしかなくてJSがある状態だから
ハイドレート（hydrate）
React のイベントや状態を有効化する仕上げ作業」
Vite
フロントエンドツールの一つ。開発サーバーの起動が早くなる。
ヴィート。
/icons/hr.icon
App Router
よく聞く。
pages ディレクトリ（旧来）から app ディレクトリ（App Router） へ移行すること。
ファイルベースルーティング。
何が良い？
元々各ファイルがそのままRouteになる
サーバーコンポーネントとか新しいデータ取得に対応している
新しいデータ取得とは？
例えば、AppRouter＋Server Componentでデータを直接コンポーネントに渡す。
Clientで余分なfetchを減らす
それに伴い進化した書き方。
before
code:tsx
// pages/index.tsx
export async function getServerSideProps() {
const data = await res.json();
return {
props: {
items: data,
},
};
}
export default function Page({ items }) {
return (
<div>
<h1>Items</h1>
{items.map((item: any) => (
<p key={item.id}>{item.name}</p>
))}
</div>
);
}
after
code:tsx
// app/page.tsx
export default async function Page() {
// デフォルトでサーバー側 fetch になる
cache: "no-store", // SSRに相当
});
const items = await res.json();
return (
<div>
<h1>Items</h1>
{items.map((item: any) => (
<p key={item.id}>{item.name}</p>
))}
</div>
);
}
pages の時は、ページでデータをサーバーから取るために必ず特別な関数を書く必要があった
getServerSideProps → props に渡す → コンポーネントで描画という「回り道」が必要
それはそうだと思ってた
/emoji/tea.iconサーバーとクライアントの境界が曖昧というか柔軟になった感じかな
そぼぎ：なんでServer ComponentはHTML作るのにServer Componentというんだろう
インタラクティブな動作などは担当しなくて「サーバー側で完結」するから
SSG
static site generation
ビルド時にHTML作っておく
サーバー側に都度データを取りに行かなくていい
動的には切り替えられない
CSR
元々はCSR（クライアントサイドレンダリング）主軸で、ブラウザが空のHTMLを受け取って巨大なJavaSctiptをダウンロードしてDOMを構築していた。
/icons/hr.icon
ディレクトリ構成やデザインパターン
Layout
それぞれのページを担当する場所？よくわからなかった。
共通部分かな
ここは再レンダリングされないみたい
ざっと一覧
ルーティングの基本単位 = フォルダ
app/page.tsx → /
app/blog/page.tsx → /blog
app/blog/id/page.tsx → /blog/123 などの動的ルート よく出てくるファイル
page.tsx：そのルートで表示する画面
layout.tsx：その配下の共通レイアウト（ヘッダー／フッターなど）
loading.tsx：そのルートのローディング UI
error.tsx：そのルート内でのエラー画面
route.ts：REST API エンドポイント（GET, POST など）を実装
サンプル1
src/
app/ # ルーティング（App Router）
components/ # 再利用可能なUIコンポーネント
ui/ # ボタン・カードなど汎用UI
layout/ # Header, Footer などページの枠組み
form/ # Input, Select などフォーム関連
features/ # ドメイン（機能）ごとにまとめる場合も
lib/ # 共通ロジック（APIクライアント、ユーティリティなど）
hooks/ # カスタムフック
types/ # TypeScriptの型定義
styles/ # グローバルCSSやテーマ関連
mocks/ # msw などのモック
ドメイン駆動とか
src/
features/
auth/
components/
hooks/
api/
todo/
components/
hooks/
api/
zod
データのバリデーション簡単にしてくれる
/icons/hr.icon
SWR
1. SWRとは何か
Vercel 製の React用データフェッチ・ライブラリ
データを取ってきて・キャッシュして・自動で更新してくれる useSWR フック
画面にはまず「手元のキャッシュ（古いかもしれない）」をすぐ表示しつつ、裏で新しいデータを取りに行く
code:tsx
import useSWR from 'swr'
const fetcher = (url: string) => fetch(url).then(res => res.json())
export default function User() {
const { data, error, isLoading } = useSWR('/api/user', fetcher)
if (isLoading) return <div>読み込み中...</div>
if (error) return <div>エラーが発生しました</div>
return <div>こんにちは、{data.name} さん</div>
}
SWRは基本「Client Component側」で使う
「初期表示のデータ」「SEOが効くべきデータ」
Server Componentで直接 fetch
「ユーザー操作で変わる動的なデータ」「後から更新したいもの」
Client Component + SWR
MSW
モックウェブサーバー用のモック（ダミーAPI）をまとめておくディレクトリ
開発・テスト中に 本物のAPIサーバーにリクエストを飛ばさずに、「こういうリクエストが来たら、こういうダミーレスポンスを返してね」という定義を書く場所。