experience-lwc-base-components-integrate

Lightning Base Components の使用

Lightning Base Components（LBC）は、Salesforce が提供する lightning-* Web コンポーネントです。このスキルは、最終的なコンポーネントの選択が可能な限り具体的になり、実際の API ドキュメントに裏付けられるよう、エージェントを適切な判断手順へ導きます。すでに存在する機能を独自に再実装することはありません。

このスキルを使用する場面

• ユーザーが UI の要件（「検索可能なドロップダウン」「レコード編集フォーム」「フッター付きモーダル」など）を説明し、適切な lightning-* コンポーネントを尋ねている場合。
• ユーザーがプリミティブ（ボタングループ、コンボボックス、トーストなど）を作ろうとしており、代わりに LBC を使うべき場合。
• ユーザーが LBC 関連の問題について LWC マークアップのレビューを依頼している場合。具体的には、SLDS クラスの上書きや LBC の内部スタイルの変更が該当します。
• 特定の lightning-* タグについて、信頼できる props／イベント／スロットの情報が必要な場合。

前提条件

• 組織で使用している LBC の名前空間を把握していること（デフォルトのパブリック名前空間は lightning です。プラットフォームによっては lightning-community などが公開されている場合があり、ユーザーのメタファイルで確認できます）。
• このスキルには、references/lightning-components.md にすべての Lightning Base Component の信頼できる API ドキュメントが含まれています。各コンポーネントは # Component API Structure ブロックとして記載されています。**Name:** <camelCaseName>（例：**Name:** datatable）を検索すると、そのコンポーネントの Properties／Methods／Events／Slots に移動できます。LBC は進化しており、このリファレンスが信頼できる情報源であるため、キャッシュされた知識に頼らず、こちらを確認してください。

ワークフロー

ステップ 1 — まずコンポーネントインデックス全体を読む

lightning-component-index.md を開き、選択する前にすべての項目に目を通してください。これは必須です。LBC の価値は、最も特化したコンポーネントを選ぶことにあります。スキャンを省略すると、プリミティブを組み合わせて複合ウィジェットを作り直すことになりかねません。

スキャンしながら、ユースケースのどの側面にでも関係するコンポーネントをすべて候補リストにまとめてください。この段階では、候補を絞り込んだり、順位を付けたりしないでください。

ステップ 2 — 機能ごとに最も適したコンポーネントへ絞り込む

スキャンが完了したら、次の手順に進みます。

• ユースケースの各機能について、それをカバーする最も特化したコンポーネントを選択してください。特化されたコンポーネントでシナリオ全体をカバーできる場合は、汎用プリミティブ（lightning-input、lightning-button）よりも、特化された複合コンポーネント（lightning-record-form、lightning-tabset、lightning-datatable）を優先してください。
• 重複を避けてください。lightning-record-form がすでにレコードの項目を表示している場合、動作を明示的に上書きするのでなければ、lightning-input-field と組み合わせないでください。

ステップ 3 — 候補リストを提示して確認を取る

各コンポーネントを選んだ理由を一行で添えて、最終候補リストを開発者に提示してください。完全な API ドキュメントを取得する前に、明示的な確認を待ってください。これにより、開発者がすでに候補から除外しているコンポーネントに、エージェントがコンテキストを費やすのを防げます。

ステップ 4 — 完全な API ドキュメントを取得する

確認が取れたら、同梱のヘルパーを使って正確な API ブロックを取得してください。これにより、大規模なリファレンスを場当たり的に grep する必要がなくなります。

scripts/extract-component-docs.sh <camelCaseName> [<camelCaseName>...]

lightning-<foo> タグを camelCase に変換してください（lightning- の接頭辞は付けません）。

• lightning-datatable → datatable
• lightning-record-edit-form → recordEditForm
• lightning-button-icon → buttonIcon

返される各ブロックは、Basic Information（タグ、名前空間、タイプ）、Properties（名前、タイプ、デフォルト値、説明）、Methods、Events、Slots、および該当する場合は使用上の注意で構成されています。このスキルはコンポーネントの選定を支援し、同梱のリファレンスはその組み込みを支援します。

Step 5 — 統合ガイダンスを作成する

コンポーネントごとのリファレンスを使って、開発者に以下の手順を案内します。

• 正確な <lightning-...> タグと必須属性。
• バインドするイベント（onchange、oncommit、onsuccess など）と、イベントペイロードの内容。
• 埋め込むスロット（ヘッダー、フッター、カスタムコンテンツ）。
• コンポーネントのドキュメントに記載されている既知の制約（例：lightning-record-form は編集／表示モードで object-api-name と record-id が必要です）。

Step 6 — LBC のスタイル規則を守る

LBC の内部にある SLDS クラスを上書きしないでください。詳細は lbc-expert-guidance.md を参照してください。 よくある問題：

• ホストコンポーネントの CSS で .slds-button や .slds-input を指定して LBC のスタイルを変更すること。LBC はシャドウルート内で動作するため、これらのセレクターは隣接するコンポーネントに漏れるか、完全に除去されます。代わりに、コンポーネントでドキュメント化されているスタイルフック（--sds-c-button-* など）を使用してください。
• 内部マークアップを変更するためだけに LBC をラップすること。できません。マークアップはシャドウルートの背後に隠されています。必要なスロット／プロパティがコンポーネントで公開されていない場合、それはプラットフォームレベルの不足であり、スタイル変更で解決する問題ではありません。

例

例 — 「入力補完機能付きの複数選択コンボボックスが必要です」

1. コンポーネントインデックスを最初から最後まで確認します。
2. 候補リストには、lightning-combobox、lightning-dual-listbox、 lightning-record-picker が含まれます。
3. 候補を絞り込みます：lightning-dual-listbox（ドキュメントで複数選択対応の基本コンポーネントとして説明されています）。lightning-combobox はドキュメントに記載された API が単一選択であり、type="multi" も複数選択モードもないため、候補から除外します。 lightning-record-picker は、値がレコード ID の場合にのみ適合することを明示します。
4. 開発者が lightning-dual-listbox を確認します。
5. scripts/extract-component-docs.sh dualListbox を実行します。
6. ブロックの Properties / Events セクションから、options、value、onchange のペイロード、および必須のラベルプロパティを提示します。

例 — 「独自のモーダルを作成します」

1. 検索で lightning-modal、lightning-modal-body、 lightning-modal-footer、lightning-modal-header が見つかります。
2. 候補は 4 つのモーダルコンポーネントです。
3. 確認します。
4. scripts/extract-component-docs.sh modal modalHeader modalBody modalFooter を実行すると、モーダル API 全体が取得できます（LightningModal の拡張方法、静的な .open() パターン、ヘッダー／本文／フッターのスロット指定）。
5. 独自のダイアログを作成しないよう、開発者に案内します。

確認チェックリスト

• コンポーネントを選択する前に、コンポーネントインデックス全体を確認した（キーワード検索で済ませていない）。
• 候補リストに、ユースケースに関わるすべてのコンポーネントを含めた。
• 最終候補では、機能ごとに最も具体的なコンポーネントを選択した。
• バンドルされたコンポーネントリファレンスを開く前に、開発者が最終候補を確認した。
• 統合ガイダンスで、実際の API ドキュメントに記載された props／events／slots を参照した（推測ではない）。
• SLDS クラスの上書きによって LBC のスタイルを変更する提案をしていない。

トラブルシューティング

• **Name:** <name> の grep で一致するものがない — 名前が間違っているか、リファレンスで別の camelCase 表記が使われています。コンポーネントインデックスで確認してください（lightning-record-form → recordForm、 lightning-record-view-form → recordViewForm、 lightning-button-icon → buttonIcon）。
• 提案したコンポーネントに、想定していたプロパティがない — 記憶よりも実際の API ドキュメントを優先してください。LBC は進化しており、キャッシュされた知識は誤っていることがあります。
• 開発者が候補の絞り込みに納得しない — Step 4 を省略しないでください。開発者が希望する選択肢についても、実際のトレードオフを確認できるよう、引き続きドキュメントを取得します。
• 開発者が LBC の内部をスタイル変更したがっている — スタイルフックを使うよう案内してください（LBC Expert リファレンスを参照）。シャドウ DOM の内部へのアクセスを拒否するのが正しい対応です。