vercel-composition-patterns

React の部品に isThread isEditing のような真偽値の引数が増えてきたときに効くスキルです。引数で振る舞いを切り替える代わりに、小さな部品を組み合わせて作る形へ寄せます。

本文が挙げる場面は、真偽値の引数が多い部品の書き直し、使い回す部品集の作成、柔軟な部品の API の設計、部品の構成の見直しです。同じ公開元の vercel-react-best-practices が性能の規則なのに対し、こちらは部品の組み方の規則です。

規則（4 分類）

8 件

同梱ファイル（2026-10-23 時点）

13 件

SKILL.md の大きさ（2026-10-23 時点）

2,886 バイト

全規則をまとめた AGENTS.md（2026-10-23 時点）

22,627 バイト

SKILL.md は目次で、中身は規則のファイル

SKILL.md には、規則の名前と 1 行の説明しかありません。悪い例と良い例のコードは rules/ の規則ごとのファイルにあり、全部を 1 枚にまとめた AGENTS.md もあります。

規則のファイルは、なぜ大事か、悪いコードの例、良いコードの例、補足、の順で書かれています。例はどれも、チャットの投稿欄（Composer）を題材にした続きものです。

8 つの規則

• 真偽値の引数を増やさない引数 1 つで状態の組み合わせが倍になる。組み合わせで作る
• 複合部品にする共有の文脈を持つ親と子の部品に分け、使う側が要る部品だけを並べる
• 状態の持ち方を UI から切り離す状態をどう管理するかを知るのは Provider だけ
• 文脈の型を決める文脈を state・actions・meta の 3 つに分けた共通の型にし、Provider を差し替えられるようにする
• 状態を Provider に持ち上げる枠の外にある部品からも状態と操作に届くようにする
• 明示的な派生を作るThreadComposer EditMessageComposer のように、用途ごとの部品を作る
• renderX より children構造を組むなら children。親から値を渡すときだけ描画関数を使う
• React 19 の書き方forwardRef を使わず ref を普通の引数に。useContext の代わりに use()

分類と重みの付き方

SKILL.md の表では、部品の構成が「HIGH」、状態の管理・実装の型・React 19 が「MEDIUM」です。規則の数は、部品の構成 2、状態の管理 3、実装の型 2、React 19 が 1 です。

要の考え方は「見た目の入れ子ではなく Provider の範囲」

文脈の型の規則にある考え方が、全体を貫いています。状態を共有したい部品どうしは、見た目の上で入れ子になっている必要はなく、同じ Provider の内側にいればよい、というものです。

本文の例では、転送のダイアログの中で、投稿欄の外にあるプレビューと送信ボタンが、投稿欄の状態を読み、送信の操作を呼んでいます。Provider を差し替えれば、同じ UI が手元の状態でも、全体で同期する状態でも動きます。

状態の持ち上げで避ける 3 つの書き方

状態の持ち上げの規則は、悪い例を 3 つ挙げています。

3 つとも、Provider に状態を持ち上げる 1 つの形で置き換えます。

性能を詰めたいとき

このスキルは部品の組み方を扱い、描画の回数や読み込みの速さは扱いません。性能なら vercel-react-best-practices です。

見た目や使い勝手を見直したいとき

画面の使い勝手や読みやすさの点検なら、同じ公開元の web-design-guidelines が合います。画面の移り変わりの動きなら vercel-react-view-transitions です。

小さな部品で、分岐が 1 つ 2 つのとき

規則は、分岐が増えて手に負えなくなった部品を前提にしています。引数が 1 つ増えただけの部品を複合部品に分けると、かえってファイルが増えます。どこまで分けるかは、使い回す範囲で決めてください。

解析で分かること

SKILL.md の解析では、外部通信・シェル実行・ファイル書き換えの記述は見つかっていません。同梱ファイルは 13 件で、規則のファイル 8 件、分類の定義と新しい規則の雛形、AGENTS.md、README.md、metadata.json です。スクリプトはありません（2026-10-23 時点）。

規則に沿って書き直させると、部品のファイルは分かれて増えます。直させる前に、どの部品まで触るかを決めてください。

React 19 の規則は版を確かめてから

重みの表記がファイルによって違う

SKILL.md と AGENTS.md は部品の構成を「HIGH」としていますが、規則のファイルでは、真偽値の引数の規則が「CRITICAL」です。README.md は分類を CRITICAL・HIGH・MEDIUM で書き、React 19 の分類を載せていません。

優先の順は、どれでも部品の構成が先頭です。表記の違いで迷ったら、規則のファイルの中身で判断してください。

例のコードは React Native 寄りの書き方を含む

例の部品は TextInput や onPress を使っていて、React Native の書き方に近い所があります。Web の React なら input と onChange に読み替えます。考え方はどちらでも同じです。

ライセンスは MIT

SKILL.md の frontmatter に MIT とあります。metadata.json は版を 1.0.0、日付を 2026 年 1 月とし、参照先に React の公式の文書を挙げています。

真偽値の引数は 1 つも使ってはいけないのですか

本文は、振る舞いを切り替えるための真偽値の引数を足すな、としています。理由は、引数が 1 つ増えるたびに状態の組み合わせが倍になり、条件分岐が手に負えなくなるからです。用途ごとの部品に分ければ、それぞれが何を描くかがコードから読めます。

描画関数を渡す書き方（render props）は使えなくなりますか

使えます。規則は、親が子に値を渡す必要があるときは描画関数がよく合う、としています。本文の例は、一覧の各項目を renderItem で描く形です。構造を組むだけなら children を使え、という使い分けです。

状態管理のライブラリは何を使えばいいですか

決めていません。本文の立場は、Provider だけが状態の持ち方を知り、UI は文脈の型だけを見る、というものです。useState でも Zustand でもサーバーとの同期でも、Provider の中に閉じ込めれば UI は変わりません。

対応しているエージェントはどれですか

Claude Code です。リポジトリの根にある AGENTS.md が、Claude Code への手動の入れ方（~/.claude/skills/ への写し）を書いています（2026-10-23 確認）。同じ文書は claude.ai での使い方にも触れていますが、当サイトの表示は Claude Code だけです。