diegosouzapw React UI Computation Skill
公式情報
発火条件（リポジトリ判定）
- まず
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
思想（判断ルール）
- コンポーネントは「UI部品」ではなく「UI計算の単位」。責務と境界を小さく保つ。
- stateは最小に。stateの置き場所は“依存する範囲の最小の上”に置く（持ち上げすぎない/分散しすぎない）。
- 再レンダリングは悪ではないが、無意味な再計算は避ける。計算コスト/DOMコスト/ネットワークコストを分けて見る。
- “どこまでクライアントに送るか”は設計。初期表示と操作体験の優先順位で決める。
- Next.js（App Router）文脈では、Server/Clientの境界（RSC/Client Component）を「責務分離」として扱う。魔法ではなく制約の設計。
進め方（質問テンプレ）
最初に必ず以下を確認してから提案する：
- これは「サイト」寄り？「アプリ」寄り？（状態・操作が多いか）
- 重要なのは初期表示？操作体験？SEO？（優先順位）
- データはどこから？更新頻度は？（キャッシュ可能性）
- 速度の課題は何？（LCP/INP/CLS/TTFB のどれ）
- ルーティング/フォーム/認証はある？（責務分離の必要性）
出力フォーマット（必ずこの順）
- 推奨方針（1〜3行）
- 理由（Web制約 / DX / 保守性 / 性能）
- 設計案（コンポーネント境界 / state配置 / データ取得 / レンダリング戦略 / バンドル・資産 / キャッシュ）
- チェックリスト（実装前に確認）
- 落とし穴（避けるべき）
- 次アクション（小さく試す順）
チェックリスト（設計/実装レビュー用）
コンポーネント境界
- コンポーネントの責務が大きすぎないか（表示・状態・副作用・データ取得が混ざりすぎてないか）
- 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/通信）が放置される