compose-component-design について
Jetpack Compose 開発者向けのコンポーネント API 設計スキルです。固定構造を保ちながら配置や可変コンテンツを呼び出し側に委ねるため、Modifier やスロットの判断手順を示します。
主な機能
- 01固定構造と可変領域の整理
- 02ルートへの Modifier 配置の指針
- 03スロットと意味的パラメーターの選択
- 04依頼範囲内に変更を限定
- 05判断に応じた参考資料への案内
活用シーン
- 01スロットとコンテンツ引数のレビュー
- 02コンポーネントのルート Modifier API の設計
- 03呼び出し側に委ねる表示領域の判断
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ chrisbanes/ skills --skill compose-component-designインストール後、Claude Code で/compose-component-designを入力して読み込まれたか確認します。
同梱ファイルreferences/modifier-layout.mdreferences/slot-apis.md
詳細
Compose コンポーネント設計
基本原則
再利用可能なコンポーネントは、呼び出し側が配置・合成できるようにします。コンポーネントは不変の構造を所有し、呼び出し側は用途に応じて変わる配置、コンテンツ、ポリシーの選択肢を保持します。
手順
- 要求された API 上の懸念事項を明示し、編集範囲をその中にとどめます。スロットに焦点を当てたレビューを、無関係な修飾子、命名、クリーンアップの変更を行う許可と解釈してはいけません。
- コンポーネントの不変の視覚構造を明示し、変化する領域、配置に関する懸念事項、ポリシーの選択肢をすべて特定します。広範な API レビューでは、どれを固定されたセマンティックコンテンツとし、どれを呼び出し側ごとに変化させるか決める前に、ハードコードされたテキストやアイコンを含め、描画されるすべての領域を洗い出します。要求に複数の懸念事項が含まれる場合は、それぞれについて報告します。有効な修飾子やスロットの指摘を最初に見つけたところで止めてはいけません。
- ルートの配置が要求された作業の一部である場合、またはコンポーネント API を広範に設計する場合は、具体的な API 境界によって別の配置が適切と判断される場合を除き、呼び出し側の修飾子を受け取り、コンポーネントのルートに適用します。ルートが条件分岐する場合は、分岐を一つのラッパーに統合せず、すべての分岐のルートに適用します。
- 呼び出し側が制御する制約のない視覚領域は、プリミティブなコンテンツパラメーターや Boolean 型の形状フラグを増やすのではなく、スロットで表現します。セマンティック上の制約やデザインシステム上の制約には、プリミティブなパラメーターを使用します。
- 単純な条件付き構造はインラインのままにし、一貫性のある再利用可能な契約のみを抽出します。
- 公開シグネチャを編集する前に、以下の該当するリファレンスを読みます。
- レビューでは、要求された可変の視覚領域ごとに、セマンティックなプリミティブとして維持するか、呼び出し側のスロットにするかを明確に判断します。コンテンツの制限を指摘するだけでは、その API の判断を行ったことにはなりません。既存の API がすでに要求された懸念事項を満たしている場合は、編集せずに終了します。それ以外の場合は、呼び出し側がコンポーネントを配置し、変化するコンテンツを提供し、隠れた切り替え機能に頼らずに所有関係を理解できる状態になった時点で終了します。
トピック案内
| シグナル | 参照先 |
|---|---|
| 修飾子パラメーター、ルートレイアウトの配置、修飾子の順序、または条件付きレイアウトラッパー | 修飾子とレイアウト |
| 呼び出し側が制御する可変の視覚領域、オプションのコンテンツ、プリミティブなコンテンツパラメーター、または Boolean 型の形状フラグ | スロット API |
| アニメーションが公開コンポーネントの契約に含まれる | Compose アニメーション |
| コンポーネントの設計中に状態の所有関係が変わる | Compose の状態とエフェクト |
| セマンティクスやスクリーンショットによるカバレッジが必要 | Compose UI テストパターン |
コメント
Markdown 対応