mcpField
R
react-boundaries

react-boundaries

github.com/dobroslavradosavljevic開発339 回インストール2 日前に更新
リポジトリ

react-boundaries について

React のコンポーネントツリーで、状態、データ取得、副作用をどの境界に置くか判断する開発スキルです。親への集約やプロパティの受け渡しを抑えつつ、連携やルーティングなどの例外も示します。

主な機能

  1. 01状態とクエリを適切な末端境界に配置
  2. 02データの受け渡しを ID と末端の購読に置換
  3. 03children とスロットによるレイアウト構成
  4. 04データを上位に置く条件の適用
  5. 05所有関係の確認と変更箇所の検証

活用シーン

  1. 01React 機能の状態所有を見直す
  2. 02プロパティの受け渡しをコンポーネント構成に置換
  3. 03ルートレベルのデータ取得の妥当性を判断

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/dobroslavradosavljevic/skills --skill react-boundaries

インストール後、Claude Code で/react-boundariesを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
anti-patterns.md
composition.md
ownership.md
tanstack-patterns.md

詳細

React Boundaries

状態、データ、副作用は、適切な最小境界で所有します。親コンポーネントは構造を組み立てますが、データハブにはなりません。

**原則:**コンポーネントは、描画と動作に必要なものを所有するべきです。ただし、別の境界で本当に調整、制御、または並行読み込みを行う必要がある場合は除きます。

基本の方針

  1. 下位に移す。 状態とフェッチは、それを使うコンポーネントで管理します。例外リストに該当する場合に限り、上位に持ち上げます。
  2. ペイロードではなく識別情報を渡す。 子には id(または安定したハンドル)を渡し、購読やクエリは子に任せます。自身では使わないエンティティを、中継するだけのラッパーに渡していくのは避けます。
  3. UIを組み立て、propsを受け渡さない。 data、isLoading、ハンドラーをレイアウト用シェル経由で渡すより、children/スロット/名前付きパーツを優先します。
  4. クライアントは共有し、フックはローカルに置く。 APIまたはQueryClientは1つにし、リーフでは複数のフックを使います。「APIを呼び出す」処理を5階層上に集約しないでください。
  5. メモ化を見せかけの解決策にしない。 memo/useCallback/useMemoをむやみに追加する前に、所有者とツリー構造を見直します。React Compilerで機能するパターンを優先します。
  6. 上位に移す場合は、理由を1行で明記します。 状態を上位に持ち上げる場合や、ルートでフェッチする場合は、「SEO」「マウント前の制御」「兄弟間の同期」「ウォーターフォール防止」のいずれかを明記します。

上位に移すのが適切な場合

状態やデータの所有を上位に移すのは、次の場合に限ります。

例外所有する場所
描画前またはメタデータ用に、ルート/SSR/SEOでデータが必要Router loader、Start server function、またはRSCのプリフェッチ
認証、権限、または「Xが満たされるまでマウントしない」制御ルートまたは親のゲート
2つ以上の兄弟コンポーネントが、1つの対話的な信頼できる情報源を共有する必要がある最も近い共通の親、または限定的なストア
フェッチ開始前に、どの子が存在するかを親が把握する必要がある親/ローダー(ウォーターフォール防止)
キャッシュが同じキーの重複をすでに排除するリーフは引き続き購読し、親はプリフェッチのみを行う

それ以外はすべて下位に置きます。詳細:ownership.md。

ワークフロー

  1. 対象範囲 — ユーザーが指定した機能、ルート、またはコンポーネントツリーを確認します。
  2. 所有関係の把握 — 状態の各要素、クエリ、ミューテーションについて、所有者と、変更時に再レンダリングされる対象を特定します。
  3. 基本方針を適用 — 所有を下位に移します。渡しているペイロードをID+リーフでの購読に置き換え、propsの受け渡しをコンポジションに置き換えます。
  4. TanStackのパターンを適用 — tanstack-patterns.md。
  5. コンポジションを確認 — composition.md。
  6. アンチパターンを排除 — anti-patterns.md。
  7. 検証 — 変更箇所の型チェック/リンター/テストを実行し、変更頻度の高い状態がページやルートのシェルに残っていないことを確認します。

配置チェックリスト

変更を終える前に、次の項目を確認します。

  • この状態やクエリが更新されたとき、どのコンポーネントが再レンダリングされますか?
  • このデータや状態を実際に使うのはどのコンポーネントですか?
  • リーフがクエリ/ミューテーションを所有できますか(または共有キーを購読できますか)?
  • 中間コンポーネントはUIを組み立てていますか。それともpropsを転送しているだけですか?
  • 上位に移した場合、どの例外に該当しますか(理由を1行で記載)?
  • Context/Storeは、ローカルに置くべき安定した依存関係や変更頻度の高い値を保持していませんか?

対象外

  • 「Contextを使わない」「ルートローダーを使わない」「propsを渡さない」という方針ではありません。
  • スタイルの変更、アクセシビリティ対応プリミティブの設計、React API全般のドキュメントは対象外です。
  • TanStack Queryを、場当たり的な親のuseEffectによるフェッチに置き換えるものではありません。

完了時

次の内容を簡潔に報告します。

  • 所有関係の変更(何を下位に移したか、または上位に残したか、その理由)。
  • propsのバケツリレーやデータハブの解消。
  • プリフェッチと購読の使い分け(該当する場合)。
  • 例外に基づく理由を添えた、上位に残した項目。

コメント