# React

> React/Next.jsプロジェクトで、UI=計算モデル（コンポーネント/状態/レンダリング）を軸に、設計・実装・レビュー・性能改善の判断を整理する。React、Next.js、JSX、コンポーネント設計、useState/useEffect、状態管理、Server Components、SSR/SSG/Streaming、App Router、バンドル最適化、再レンダリング問題に関する相談で必ず使うこと。ユーザーが「コンポーネントの分割」「stateの置き場所」「パフォーマンスが遅い」「RSCの使い分け」と言った場合にも適用する。

- Skill: `mae616/react` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mae616/react`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mae616/react/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: mae616 (https://skillmd.com/u/mae616)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mae616/react

---


# React UI Computation Skill

## 公式情報
- [React](https://react.dev)
- [React Docs](https://react.dev/learn)
- [Next.js](https://nextjs.org)
- [Next.js Docs](https://nextjs.org/docs)

## このSkillの基本方針
- UIは「状態→描画」の計算。コンポーネントは計算単位として設計する。
- レンダリング: SSR/CSR/SSG/Streamingは“いつUIを完成させるか”の設計。要件（SEO/速度/更新頻度）から選ぶ。
- 境界: 「クライアントに送るJS」と「サーバーに置く処理」の境界を意識する。送らない最適化は強い。
- パフォーマンス: 体感（LCP/INP/CLS）に効く順に当てる。JS送信量・画像・フォント・3rd partyを疑う。
- 参考: [React](https://react.dev) / [Next.js](https://nextjs.org)

## 思想（判断ルール）
1. コンポーネントは「UI部品」ではなく「UI計算の単位」。責務と境界を小さく保つ。
2. stateは最小に。stateの置き場所は“依存する範囲の最小の上”に置く（持ち上げすぎない/分散しすぎない）。
3. 再レンダリングは悪ではないが、無意味な再計算は避ける。計算コスト/DOMコスト/ネットワークコストを分けて見る。
4. “どこまでクライアントに送るか”は設計。初期表示と操作体験の優先順位で決める。
5. Next.js（App Router）文脈では、Server/Clientの境界（RSC/Client Component）を「責務分離」として扱う。魔法ではなく制約の設計。

## 進め方（質問テンプレ）
最初に必ず以下を確認してから提案する：
- これは「サイト」寄り？「アプリ」寄り？（状態・操作が多いか）
- 重要なのは初期表示？操作体験？SEO？（優先順位）
- データはどこから？更新頻度は？（キャッシュ可能性）
- 速度の課題は何？（LCP/INP/CLS/TTFB のどれ）
- ルーティング/フォーム/認証はある？（責務分離の必要性）

## 出力フォーマット（必ずこの順）
1. 推奨方針（1〜3行）
2. 理由（Web制約 / DX / 保守性 / 性能）
3. 設計案（コンポーネント境界 / state配置 / データ取得 / レンダリング戦略 / バンドル・資産 / キャッシュ）
4. チェックリスト（実装前に確認）
5. 落とし穴（避けるべき）
6. 次アクション（小さく試す順）

## チェックリスト（設計/実装レビュー用）
### コンポーネント境界
- [ ] コンポーネントの責務が大きすぎないか（表示・状態・副作用・データ取得が混ざりすぎてないか）
- [ ] propsの受け渡しが深すぎないか（必要ならContextや分割を検討）
- [ ] 再利用のための抽象化が早すぎないか（読みにくさが勝ってないか）

### state・副作用
- [ ] stateが最小か（derived stateを持ってないか）
- [ ] effectは「同期の穴埋め」になっていないか（まずデータフローを疑う）
- [ ] 非同期処理の責務（ロード/エラー/リトライ）がUIと分離できているか

### レンダリング・配信
- [ ] SSR/CSR/SSG/Streamingの選択理由が説明できるか
- [ ] クライアントに送るJS量を説明できるか（“送らない”選択肢を検討したか）
- [ ] 画像/フォント/3rd partyが体感を壊していないか

### Next.js（該当時）
- [ ] Server/Client境界が妥当か（Clientに寄せすぎてないか）
- [ ] データ取得をUIの近くに置きつつ、秘密情報がクライアントに漏れないか
- [ ] キャッシュ方針（更新頻度/再生成/無効化）が言語化できるか

## よくある落とし穴
- 「とりあえず全部Client」にして送信量が膨らみ、初期表示とINPが悪化する
- stateが持ち上がりすぎて、少しの変更で全体が再レンダリングされる設計になる
- derived stateを増やして、同期ズレ・バグ・複雑性が増える
- useEffectで辻褄合わせを始めて、原因（データフロー/責務）が見えなくなる
- パフォーマンス改善が“メモ化の儀式”になり、真因（画像/3rd party/通信）が放置される