Sitecoreの動的プレースホルダーとJSS
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
動的プレースホルダーはSitecore 9.0で導入されました。JSSはこの機能を活用し、JSSアプリケーション内でレイアウトやコンテンツを動的に制御しています。
Sitecoreアーキテクチャの中心的な部分は、プレースホルダーキーを用いてコンポーネントの位置を特定するデータ駆動型のページレイアウトです。
コンポーネントはコードやマークアップで利用可能なプレースホルダーを定義し、ページ上に定義されたプレースホルダーに従って配置されます。プレースホルダーアドレスは通常、完全修飾パスであり、すり線('/')で区切られたプレースホルダーの階層全体を含みます。これはURLパスに似ています。
以下のアニメーションは、Sitecoreレイアウトエンジンがどのようにページレイアウトを構成しているかを示しています。
このシステムの欠点は、同じコンポーネントを同じプレースホルダーアドレスに複数回配置しようとすると明らかになります。
以下の例レイアウトでは、プレースホルダーパス /phContent/phTabが与えられた場合、タブをどのタブコンポーネントに入れるべきかが不明瞭です。箱から出すと、Sitecore最初のタブコンテナにタブコンポーネントを配置します。
この問題を解決するためには、プレースホルダーキーは動的でなければなりません。考えられるアプローチには以下があります:
- コンポーネントの位置に基づいてプレースホルダーキーにインデックスを付けます。例えば、 /phContent/phTab_1。
- ページ上に配置されたコンポーネントに割り当てられる一意識別子(UID)をSitecoreします。例えば、 /phContent/phTab_8DFE46A3-5D17-43E1-835D-129D18BD59AC。
- 前のアプローチの組み合わせです。
UIDアプローチは、Experience EditorやHorizonなどの高度なSitecoreエディターでコンポーネントを移動させるシナリオにおいて最も耐久性が高いです。
Sitecore JSSにおける動的プレースホルダー
JSSでSitecoreの動的プレースホルダーを使うにはいくつかの課題があります:
- アプリケーションはSitecoreなしでレンダリングが可能でなければならず、アプリケーションおよびそのコンポーネントをSitecoreにインポートする前にUIDのレンダリングアクセス権を持ちません。
- 開発者はJavaScriptオブジェクトでコンポーネントレイアウトを構築しており、Sitecoreレイアウトエンジンの欠点が自分たちのレイアウトに影響を受けるかどうかを考慮したくないと考えています。
- 同様に、プレースホルダーをコンポーネントに追加する際、開発者はプレースホルダーが動的である必要があるかどうかを考慮したくありません。
これらの課題を克服するために、Sitecore JSSは以下の設計上の決定を行いました。
- ページ上のコンポーネントをアドレス指定する代わりに、ツリーやネストされたルートレイアウト構造を利用しましょう。JSSで消費されるルートデータは、子コンポーネントをプレースホルダーコレクション内に配置しなければならず、レイアウト内のどこにコンポーネントを配置するかに曖昧さはありません。
- コンポーネントをインポートしデータをSitecoreにルーティングする際は、すべてのプレースホルダーが動的であると仮定してください。ただし、ルートの子ポストホルダーの直接的な子は例外です。
- レンダリングUIDを含む動的なプレースホルダー形式を活用してください。
- Sitecoreインポート前にマニフェストを作成する際にレンダリングUIDを生成してください。この戦略により、必要に応じて動的プレースホルダー形式の柔軟性が高まります。