reactlisted

# 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) ## 発火条件（リポジトリ判定） - まず `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](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や分割を検討）