modern-best-practice-react-components
現代的なReactコンポーネントを、不要な状態管理やuseEffectの濫用といったよくある落とし穴を避け、一般的なベストプラクティスを適用して、より洗練された形で構築するSkill。
📜 元の英語説明(参考)
Build clean, modern React components that apply common best practices and avoid common pitfalls like unnecessary state management or useEffect usage
🇯🇵 日本人クリエイター向け解説
現代的なReactコンポーネントを、不要な状態管理やuseEffectの濫用といったよくある落とし穴を避け、一般的なベストプラクティスを適用して、より洗練された形で構築するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o modern-best-practice-react-components.zip https://jpskill.com/download/9095.zip && unzip -o modern-best-practice-react-components.zip && rm modern-best-practice-react-components.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/9095.zip -OutFile "$d\modern-best-practice-react-components.zip"; Expand-Archive "$d\modern-best-practice-react-components.zip" -DestinationPath $d -Force; ri "$d\modern-best-practice-react-components.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
modern-best-practice-react-components.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
modern-best-practice-react-componentsフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
Reactコンポーネントの記述
私たちはモダンなReact (19+) を使用しており、明確さ、正確さ、保守性に焦点を当てた一般的なベストプラクティスに従っています。
コンポーネントの構造とスタイル
- 推奨 単一の責任を持つ、小さく焦点を絞ったコンポーネント
- 推奨 アロー関数よりも名前付きの
functionコンポーネント- 例外: 匿名コールバック、インラインレンダープロパティ、クロージャ
- 推奨 該当する場合は、明示的な戻り値の型とpropsの型付け (TypeScript)
- コンポーネントをフラットで読みやすく保ちます。深くネストされたJSXは避けてください
- 関連するロジックをまとめてグループ化します (イベントハンドラ、派生値、ヘルパー)
状態管理
- 回避
useEffect()- 詳細なガイダンスについては、"You Might Not Need An Effect" guide を参照してください
- 推奨 状態を同期する代わりに、レンダリング中に値を派生させる
- TanStack Query (
@tanstack/react-query) を介してデータをフェッチする
- 回避 不必要な
useState()またはuseReducer()の使用- 可能であれば、propsまたは他の状態から状態を派生させる
- 状態を可能な限り低いコンポーネントにローカライズする
- 絶対に必要でない限り、状態にpropsをミラーリングしないでください
- 制御されたコンポーネントを、制御されていない状態の同期よりも優先する
レンダリングと派生
- 推奨 派生値をインラインまたはヘルパー関数を介して計算する
useMemo()は控えめに、実績のあるパフォーマンスの問題に対してのみ使用する- 回避 早すぎる最適化
- レンダリングロジックを決定論的に保ち、副作用がないようにする
イベント処理
-
回避 JSXでのインラインイベントハンドラ
-
推奨:
function handleClick() { // ... } <button onClick={handleClick} />; -
次の記述よりも推奨:
<button onClick={() => { /* ... */ }} />
-
-
ハンドラに明確な名前を付ける (
handleSubmit,handleChange,handleClose) -
ハンドラを小さく保ちます。複雑なロジックをヘルパーに抽出する
エフェクト、データ、副作用
- 次のエフェクトは回避してください:
- 派生状態
- データ変換
- ハンドラに存在する可能性のあるイベントベースのロジック
- 副作用が避けられない場合は、それらを最小限に抑え、分離し、十分に文書化してください
- 生のエフェクトよりも、フレームワークレベルまたは外部の抽象化 (ルーター、データライブラリ) を優先する
Propsとコンポジション
- 推奨 設定よりもコンポジション
- 回避 過剰なブール値のprops。表現力豊かなAPIを優先する
childrenを意図的に使用し、期待される構造を文書化する- prop名を意味的で予測可能に保つ
パフォーマンスと安定性
- 推奨 必要な場合にのみ安定した参照を使用する (デフォルトではない)
- 回避 絶対に必要な場合を除き、不要なメモ化 (
memo,useCallback) - リストをレンダリングするときは、キーを安定させ、意味のあるものにする
一般原則
- まず人間のためにコードを書き、次にコンパイラのために書く
- 巧妙さよりも明示性を優先する
- 読みやすさと長期的なメンテナンスのために最適化する
- パターンが複雑に感じる場合は、コンポーネントの境界を再検討する
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Writing React Components
We're using modern React (19+) and we're following common best practices focused on clarity, correctness, and maintainability.
Component Structure & Style
- PREFER small, focused components with a single responsibility
- PREFER named
functioncomponents over arrow functions- Exception: anonymous callbacks, inline render props, and closures
- PREFER explicit return types and props typing (TypeScript) where applicable
- Keep components flat and readable; avoid deeply nested JSX
- Group related logic together (event handlers, derived values, helpers)
State Management
- AVOID
useEffect()- See the "You Might Not Need An Effect" guide for detailed guidance
- PREFER deriving values during render instead of synchronizing state
- Fetch data via TanStack Query (
@tanstack/react-query)
- AVOID unnecessary
useState()oruseReducer()usage- Derive state from props or other state when possible
- Localize state to the lowest possible component
- DO NOT mirror props in state unless absolutely necessary
- Prefer controlled components over syncing uncontrolled state
Rendering & Derivation
- PREFER computing derived values inline or via helper functions
- Use
useMemo()sparingly and only for proven performance issues - AVOID premature optimization
- Keep render logic deterministic and free of side effects
Event Handling
-
AVOID in-line event handlers in JSX
-
PREFER:
function handleClick() { // ... } <button onClick={handleClick} />; -
Over:
<button onClick={() => { /* ... */ }} />
-
-
Name handlers clearly (
handleSubmit,handleChange,handleClose) -
Keep handlers small; extract complex logic into helpers
Effects, Data, and Side Effects
- AVOID effects for:
- Derived state
- Data transformations
- Event-based logic that can live in handlers
- If side effects are unavoidable, keep them minimal, isolated, and well-documented
- Prefer framework-level or external abstractions (routers, data libraries) over raw effects
Props & Composition
- PREFER composition over configuration
- AVOID excessive boolean props; prefer expressive APIs
- Use
childrenintentionally and document expected structure - Keep prop names semantic and predictable
Performance & Stability
- PREFER stable references only when required (not by default)
- AVOID unnecessary memoization (
memo,useCallback) unless absolutely required - Keep keys stable and meaningful when rendering lists
General Principles
- Write code for humans first, compilers second
- Prefer explicitness over cleverness
- Optimize for readability and long-term maintenance
- If a pattern feels complex, reconsider the component boundary