react

name	react
category	tech
user-invocable	false
description	React/Next.jsのプロジェクトで、UI=計算モデル（コンポーネント/状態/レンダリング）を軸に、設計・実装・レビュー・性能改善の判断を整理する。doc/input/rdd.md に「技術スタック React」または「技術スタック Next.js」があるリポジトリ、あるいはReactの状態管理/レンダリング/Server Components/SSR/Streaming/バンドル/パフォーマンス相談で使う。

React UI Computation Skill

公式情報

• React
• React Docs
• Next.js
• Next.js Docs

発火条件（リポジトリ判定）

• まず doc/input/rdd.md を確認し、技術スタック React または 技術スタック Next.js があれば、このSkillの方針をデフォルト採用する。
• 記載がなくても、依頼がReact/Next/コンポーネント設計/状態管理/レンダリング/SSR/パフォーマンス最適化なら適用する。

このSkillの基本方針（まえちゃん向けの“整理軸”）

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

思想（判断ルール）

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/通信）が放置される