JSS Angularアプリでのプレースホルダーの操作
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
プレースホルダー は、Sitecore JSSで構築されたアプリケーションに不可欠なコンポーネントです。例を示すために、このトピックではSitecore JSS Angularサンプル アプリケーションを使用します。
JSS Angularサンプルアプリケーションには、ルートプレースホルダーが付属しています。ルートプレースホルダはsrc/app/routing/layout/layout.component.htmlで定義されています。
sc-placeholderコンポーネントは、Sitecore JSS for Angularからインポートされます @sitecorelabs/sitecore-jss-angular。
sc-placeholder Angularコンポーネントには、値jss-mainのname属性があり、jss-mainという名前のSitecoreプレースホルダーを表していることを示しています。プレースホルダは、プレースホルダコンポーネントのrendering入力にバインドされたデータで示されるように、ルートデータに基づいて1つ以上のコンポーネントをレンダリングします。
既存のDOM要素に属性としてsc-placeholderを適用できます。
ルートデータの発信元を理解する
ルートデータの発信元を理解する
プレースホルダーコンポーネントがrouteデータをどのように受け取るかを理解するには、さまざまなコンポーネント、アプリケーションモジュール、およびサービスがどのように連携するかを理解する必要があります。
本番環境では、JSS Angularアプリケーションをビルドするためのスクリプトは、ユニバーサルレンダリングをサポートするためのサーバーバンドルとクライアントバンドルをビルドします。スクリプトjss buildを実行すると、バンドルは次の場所にあります。
-
Client bundle - dist/browser/にあります。
-
Server bundle - dist/server.bundle.jsにあります。
2つのバンドルを独立して実行することはできません。これらはサーバーによって提供されなければなりません。JSSには、サーバー バンドルを実行できるNodeのJavaScriptビュー エンジンが付属しています。JSS JavaScriptビューエンジンは、renderView関数をエクスポートするserver bundleを想定しています。
2つのバンドルをビルドして提供するために、JSS Angularアプリは、関連するアプリ モジュールとデータ サービスと共に、アプリケーションの2つのエントリ ポイントを定義します。
このファイルsrc/main.server.tsは、サーババンドルのエントリポイントを定義し、src/app/app.server.module.tsで定義されているサーバAppServerModuleのアプリケーションモジュールをブートストラップします。AppServerModuleは、src/app/jss-context.server-side.service.tsで定義されているJssContextServerSideServiceを使用します。このAPIは、サーバー上で実行され、JSSアプリのコンテキストデータを格納します。コンテキスト データには、現在のルートとSitecoreコンテキスト データのデータが含まれます。
このファイルsrc/main.tsは、クライアント バンドルのエントリ ポイントを定義し、src/app/app.module.tsで定義されているクライアント レンダリングAppModuleのアプリケーション モジュールをブートストラップします。AppModuleは、src/app/jss-context.service.tsで定義されているJssContextServiceを使用します。このは、クライアント(ブラウザー内)で実行され、JSSアプリのコンテキストデータを格納します。
アプリケーションがサーバーバンドルからブラウザーで実行されると、サーバーはAppServerModuleをレンダリングするrenderView関数を呼び出し、JSSアプリのコンテキストデータを準備します。実装の詳細については、ファイルserver.bundle.tsおよび関連サービスを参照してください。どちらのコンテキストサービスもAngular TransferStateクラスを使用します。このクラスは、データを正規化した後、サーバー側のアプリケーション・モジュールからクライアント側のアプリケーション・モジュールに転送されるキー値ストアです。
クライアント側のAppModuleは、src/app/app.component.tsで定義されているルートアプリケーションコンポーネントAppComponentをブートストラップし、src/app/routing/routing.module.tsファイルで定義されているRoutingModuleクラスをインポートします。RoutingModuleは、Angularルーターをアプリケーション ルートにアタッチし、JSS AngularアプリがAngularルーター アウトレットを使用できるようにする役割を担います。
このRoutingModuleは、ルーターのアウトレットプレースホルダーにレンダリングされるコンポーネントを定義します。このコンポーネントは、src/app/routing/layout/layout.component.tsファイルで定義されているLayoutComponentです。RoutingModuleは、ルートを解決するときにアクティブ ルートの状態を設定するJssRouteResolverプロバイダーを使用します。
最後に、routeデータとレイアウト データの両方が挿入されたLayoutComponentは、アクティブ ルートをサブスクライブし、Sitecoreコンテキストからルート データを抽出できます。
この時点で、プレースホルダーコンポーネントは、本番環境の設定でルートのHTMLマークアップをレンダリングできます。
切断モードで作業している場合、JSSアプリケーションはローカルに定義されたファイルから経路データを取得します。サンプル アプリケーションには、src/dataフォルダーに定義済みのローカル データが含まれています。ルート (ホーム ページなど) を読み込むとき、アプリケーションはsrc/data/en.ymlファイルからデータを取得します。レスポンスには、ルートのJSONデータが含まれています。
routeプロパティのJSONデータ構造には、placeholdersのリストが含まれています。各プレースホルダー名は、コンポーネントの配列に関連付けられています。コンポーネントとプレースホルダのマッピングをcomponent placement rulesと呼びます。
sc-placeholderコンポーネントはrouteプロパティ内のplaceholdersオブジェクトにアクセスできるため、一致するプレースホルダを名前 (jss-main) で検索し、その中のコンポーネントの配列をレンダリングします。この例では、ContentBlockComponentコンポーネントである通常のAngularコンポーネントを動的にレンダリングし、依存関係挿入トークンを通じてheadingフィールドとcontentフィールドを提供します。
renderingプロパティには、データから取得されるContentBlockComponentコンポーネントに関するすべての情報が含まれます。
プレースホルダーとコンポーネントのネスト
プレースホルダーとコンポーネントのネスト
構成部品には独自のsc-placeholder構成部品を含めることができるため、構成部品配置規則のplaceholdersを使用してその内容を定義できます。
たとえば、WelcomeComponentコンポーネントには次のものが含まれる場合があります。
この場合、コンポーネント配置ルールで子コンポーネントを定義します。
入力と出力のバインディング
入力と出力のバインディング
コンポーネントのカスタム・プロパティーは、sc-placeholderのinputsおよびoutputsバインディング・プロパティーを使用して、コンポーネントにバインドできます。これらのプロパティを使用すると、プレースホルダー内のすべてのコンポーネントのプロパティへの入力と出力のバインドが可能になります。
これにより、子コンポーネントがsc-placeholderによって動的に作成される場合でも、子コンポーネントとのオーケストレーション/インタラクションが可能になり、Sitecore XPを通じて管理/最適化したい複雑なユーザー フローで特に役立ちます。
次に、inputsとoutputsの簡単な使用例を示します。
遅延読み込みプレースホルダー
遅延読み込みプレースホルダー
Sitecoreコンポーネントを遅延読み込みすると、プレースホルダーはデフォルトで空で表示されます。コンポーネントのロード中に表示されるコンポーネントの一時的な本文を指定できます。コンポーネントの読み込みが完了すると、一時的な本体が実際の内容に置き換えられます。次に、簡略化した例を示します。
プレースホルダーの強化
プレースホルダーの強化
Placeholderコンポーネントは、開発者のエクスペリエンスを向上させることができるいくつかのカスタマイズをサポートしています。
エラーコンポーネント
プレースホルダーでレンダリングエラーが発生した場合、プレースホルダーはプレースホルダーの内容の代わりにエラーコンポーネントを表示し、エラーの詳細をコンソールに記録します。このコンポーネントは、errorComponent propを使用して独自のReactコンポーネントを置き換えることでカスタマイズできます。
欠落しているコンポーネントコンポーネント
プレースホルダーにcomponentFactory不明なレンダリング名が含まれている場合 (たとえば、バックエンド開発者がFooレンダリングを作成してページに追加するが、まだfoo.component.tsがない場合)、レンダリングはAngularコンポーネントのmissingComponentComponentプロパティで定義されたMissingComponentコンポーネントに置き換えられます。デフォルトの実装は単純なメッセージですが、missingComponentComponentプロパティで独自のAngularコンポーネントを使用してカスタマイズできます。
非表示のレンダリングの処理
レンダリングがパーソナライゼーションルールによって非表示になっている場合、レンダリングにJSS実装がない場合のエラーメッセージを防ぐために、レンダリングはHiddenRenderingコンポーネントに置き換えられます。独自のコンポーネントを作成し、hiddenRenderingComponentプロパティを使用してプレースホルダに提供できます。