--- title: "Sitecoreの動的プレースホルダーとJSS" slug: "sitecore-dynamic-placeholders-and-jss" abstract: "JSSがSitecore動的プレースホルダーの課題にどのように対処しているかの概要" --- # Sitecoreの動的プレースホルダーとJSS [動的プレースホルダーは](https://doc.sitecore.com/xp/en/developers/102/sitecore-experience-manager/dynamic-placeholders.html)Sitecore 9.0で導入されました。JSSはこの機能を活用し、JSSアプリケーション内でレイアウトやコンテンツを動的に制御しています。 Sitecoreアーキテクチャの中心的な部分は、プレースホルダーキーを用いてコンポーネントの位置を特定するデータ駆動型のページレイアウトです。 コンポーネントはコードやマークアップで利用可能なプレースホルダーを定義し、ページ上に定義されたプレースホルダーに従って配置されます。プレースホルダーアドレスは通常、完全修飾パスであり、すり線('/')で区切られたプレースホルダーの階層全体を含みます。これはURLパスに似ています。 以下のアニメーションは、Sitecoreレイアウトエンジンがどのようにページレイアウトを構成しているかを示しています。 ![Sitecore layout composition](https://doc.sitecore.com/api/markdown-image/xp/ja/developers/hd/19/sitecore-headless-development/images/sitecore-layout.gif) このシステムの欠点は、同じコンポーネントを同じプレースホルダーアドレスに複数回配置しようとすると明らかになります。 以下の例レイアウトでは、プレースホルダーパス /phContent/phTabが与えられた場合、タブをどのタブコンポーネントに入れるべきかが不明瞭です。箱から出すと、Sitecore最初のタブコンテナにタブコンポーネントを配置します。 ![Dynamic Sitecore Placeholders - shortcomings of a Sitecore layout without dynamic keys](https://doc.sitecore.com/api/markdown-image/xp/ja/developers/hd/19/sitecore-headless-development/images/which-placeholder.png) この問題を解決するためには、プレースホルダーキーは動的でなければなりません。考えられるアプローチには以下があります: - コンポーネントの位置に基づいてプレースホルダーキーにインデックスを付けます。例えば、 /phContent/phTab\_1。 - ページ上に配置されたコンポーネントに割り当てられる一意識別子(UID)をSitecoreします。例えば、 /phContent/phTab\_8DFE46A3-5D17-43E1-835D-129D18BD59AC。 - 前のアプローチの組み合わせです。 UIDアプローチは、Experience EditorやHorizonなどの高度なSitecoreエディターでコンポーネントを移動させるシナリオにおいて最も耐久性が高いです。 ![Sitecore layout with uniquely identifiable components](https://doc.sitecore.com/api/markdown-image/xp/ja/developers/hd/19/sitecore-headless-development/images/dynamic-placeholder.png) ## Sitecore JSSにおける動的プレースホルダー JSSでSitecoreの動的プレースホルダーを使うにはいくつかの課題があります: - アプリケーションはSitecoreなしでレンダリングが可能でなければならず、アプリケーションおよびそのコンポーネントをSitecoreにインポートする前にUIDのレンダリングアクセス権を持ちません。 - 開発者はJavaScriptオブジェクトでコンポーネントレイアウトを構築しており、Sitecoreレイアウトエンジンの欠点が自分たちのレイアウトに影響を受けるかどうかを考慮したくないと考えています。 - 同様に、プレースホルダーをコンポーネントに追加する際、開発者はプレースホルダーが動的である必要があるかどうかを考慮したくありません。 これらの課題を克服するために、Sitecore JSSは以下の設計上の決定を行いました。 - ページ上のコンポーネントをアドレス指定する代わりに、ツリーやネストされたルートレイアウト構造を利用しましょう。JSSで消費されるルートデータは、子コンポーネントをプレースホルダーコレクション内に配置しなければならず、レイアウト内のどこにコンポーネントを配置するかに曖昧さはありません。 - [切断モードで](https://doc.sitecore.com/xp/ja/developers/hd/19/sitecore-headless-development/start-a-jss-app-in-disconnected-mode.html "Start a JSS app in disconnected mode")は、これは開発者が作成したルートデータ構造に過ぎません。 - [接続](https://doc.sitecore.com/xp/ja/developers/hd/19/sitecore-headless-development/start-a-jss-app-in-connected-mode.html "Start a JSS app in connected mode")および[統合](https://doc.sitecore.com/xp/ja/developers/hd/19/sitecore-headless-development/start-a-jss-app-in-integrated-mode.html "Start a JSS app in integrated mode")モードでは、動的なプレースホルダーキーを含むSitecoreのレイアウトデータがレンダリング前にネスト構造に変換されます。 - コンポーネントをインポートしデータをSitecoreにルーティングする際は、すべてのプレースホルダーが動的であると仮定してください。ただし、ルートの子ポストホルダーの直接的な子は例外です。 - レンダリングUIDを含む動的なプレースホルダー形式を活用してください。 - Sitecoreインポート前にマニフェストを作成する際にレンダリングUIDを生成してください。この戦略により、必要に応じて動的プレースホルダー形式の柔軟性が高まります。