Skills Guide

React - Conception UI et optimisation

VérifiéSûr

Ce skill structure la conception, la revue et l'optimisation des performances des interfaces React/Next.js, en considérant l'UI comme un modèle de calcul (composants/état/rendu). Il est activé pour les projets listant React ou Next.js dans `doc/input/rdd.md`, ou lors de discussions sur l'état, le rendu, les Server Components, le SSR, le streaming, le bundling et les performances. Il fournit des checklists et des pièges à éviter pour une architecture propre et performante.

Spar Skills Guide Bot
DeveloppementAvancé
17002/06/2026
Claude Code
#react#nextjs#component-design#performance#ssr

Recommandé pour

Développeur backendClaude CodeRevue de codeDéveloppeur frontendDéveloppeur fullstackRefactoring

Notre avis

Ce skill guide la conception, l'implémentation et l'optimisation de projets React/Next.js en considérant l'UI comme un modèle de calcul (composants, état, rendu).

Points forts

  • Approche systématique basée sur les principes de rendu et de gestion d'état
  • Couverture complète de Next.js App Router, SSR, Streaming et Server Components
  • Checklists détaillées pour les revues de conception et de code
  • Accent sur les métriques de performance réelles (LCP, INP, CLS)

Limites

  • Nécessite une bonne connaissance préalable de React/Next.js pour tirer parti des recommandations
  • Peut être trop rigide pour des projets très simples ou des prototypes rapides
  • Ne couvre pas les tests unitaires ou d'intégration spécifiques
Quand l'utiliser

Pour tout développement ou réarchitecture de projet React/Next.js nécessitant une architecture robuste, des performances optimisées et une séparation claire des responsabilités.

Quand l'éviter

Pour des projets statiques simples sans logique interactive complexe, ou lorsque l'équipe n'a pas l'expérience suffisante pour appliquer les principes avancés.

Analyse de sécurité

Sûr
Score qualité88/100

This skill provides advisory guidelines for React/Next.js UI design. It does not invoke any tools, execute code, or perform any dangerous actions. No security concerns.

Aucun point d'attention détecté

Exemples

Profile page with SSR and streaming
Design a React component for a user profile page in a Next.js app. It should fetch user data and recent posts, use SSR for initial load, and stream the posts part. Include loading states and handle errors. Focus on component boundaries, state placement, and rendering strategy.
Performance review of a Next.js app
Review my Next.js e-commerce app for performance issues. I'm concerned about LCP and INP. Check JS bundle size, image optimization, third-party scripts, and suggest improvements using Server Components and streaming where appropriate.
Refactor state management with Context
I have a deeply nested prop drilling problem in my React app. Should I use Context or composition? The state is a user's theme and authentication status. Suggest the best approach and explain the trade-offs.

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

公式情報

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

  • まず 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/通信）が放置される
Skills similaires

Expert Next.js App Router

Developpement

Un skill qui transforme Claude en expert Next.js App Router.

Claude CodeCursoradvanced
890
234
2,846
Admin

Générateur de README

Developpement

Crée des README.md professionnels et complets pour vos projets.

claudeCursorWindsurfbeginner
259
72
821
Admin

Rédacteur de Documentation API

Developpement

Génère de la documentation API complète au format OpenAPI/Swagger.

claudeCursorWindsurfintermediate
156
44
682
Admin