コンポーネント工場
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
JSSアプリがページをレンダリングする際、Sitecoreから取得したレイアウトデータJSONを経由して、ページ上でどのコンポーネントをレンダリングするかを判断します。しかし、Sitecoreのレンダリング名とJSSコンポーネントをマッチさせる方法がないため、ページはレンダリングできません。
コンポーネントファクトリーは、JSSアプリがレンダリングとコンポーネントをマッチングするために使用するSitecoreレンダリングとJSSコンポーネント実装の間のマッピングです。すべてのJSSサンプルアプリケーションにはコンポーネントファクトリー実装があり、これはレンダリング名をパラメータとして受け入れ、関連するJSSコンポーネントを返すJavaScript関数です。
以下はコンポーネントファクトリーの簡略化された例です:
import * as ContentBlock from 'src/components/ContentBlock'; import * as AnotherComponent from 'src/components/AnotherComponent';
const components = new Map(); components.set('ContentBlock', ContentBlock); components.set('AnotherComponent', AnotherComponent);
export function componentModule(componentName: string) { return components.get(componentName); };
export function componentFactory(componentName: string) { return components.get(componentName)?.default; };
コンポーネントファクトリーの生成
ほとんどのJSSサンプルアプリケーションでは、コンポーネントファクトリーはビルド時にアプリケーションのコンポーネントディレクトリを再帰的に検査することでプログラム的に生成されます。コンポーネントファクトリー内でマッピングを生成するロジックはscripts/generate-component-factory.ts|jsファイルに定義されています。このファイルは異なるプロジェクト構造をサポートするようにカスタマイズでき、フラットまたはネストされたディレクトリ構造でも動作します。
コンポーネントファクトリーのプログラム生成は必須ではありませんが、新しいコンポーネントを手動で登録する必要がなくなり、開発が容易になります。
!注JSS React Nativeアプリケーションには、サンプルコンポーネントファクトリーがsrc/componentFactory.jsで定義されています。マッピングは手動で維持する必要があります。
ローカル開発サーバー上でアプリケーションを実行する際、アプリケーションはコンポーネントディレクトリの変更を監視し、新しいコンポーネントでコンポーネントファクトリーを自動的に更新します。
JSS Angularアプリケーションの場合、コンポーネントファクトリーはアプリケーションを初めて実行したときにパスsrc/app/components/app-components.module.tsで生成されます。
JSS Next.jsアプリケーションの場合、コンポーネントファクトリーはアプリケーションを初めて実行した際にパスsrc/temp/componentFactory.tsで生成されます。
JSS ReactおよびVue.jsアプリケーションの場合、コンポーネントファクトリーはアプリケーションを初めて実行した際にパスsrc/temp/componentFactory.jsで生成されます。
コンポーネントファクトリーと粒状部品
現代の開発手法では、各コンポーネントが単一の明確な責任を持つ細分化コンポーネントの使用を推奨しています。
Sitecoreレンダリングはオーサリングの概念であり、JSSコンポーネントは開発者向けの概念です。ほとんどの場合、SitecoreレンダリングとJSSコンポーネントは同じものを表しますが、対応するSitecoreレンダリングと同じデータを表現するために、より小さくてより限定的なコンポーネントの方が好ましいかもしれません。
例えば、検索結果を表示するためのレンダリングを考えてみましょう。コンテンツ作成者にとっては、検索結果領域全体が単一のユーザーインターフェース要素です。しかしフロントエンド開発者にとって、検索結果表示領域はコンポーネントの構成です。例えば、検索結果コンテナ用のコンポーネント、すべての結果リスト項目用のコンポーネント、そして異なる結果セクション用のコンポーネントが存在する場合もあります。コンテンツ作成者は複数の検索結果のバリエーションを管理する必要がないため、レンダリングを小さな要素に分割しても価値を見いだせません。そのような方法は作業を複雑にします。しかし、JSSで細かいコンポーネントを作成する際にそうしなければ、Sitecoreレンダリングと一致しないコンポーネントが生成されます。
結論として、コンポーネントファクトリーにマッピングされるコンポーネントは、コンテンツ作成者が見るSitecoreレンダリングと一致しなければなりません。レンダリング用の検索結果コンポーネントを構築するために細かいコンポーネントを作成する際は、それらのコンポーネントをComponent Factoryに含めず、問題を回避するためにプレースホルダーを使用することを推奨します。
代わりに、細かいコンポーネントを他のすべてのコンポーネントとは異なるディレクトリに配置することを推奨します。JSSアプリケーションで主コンポーネントディレクトリがsrc/componentsされている場合、開発専用コンポーネントはsrc/helpersやsrc/containersなどのディレクトリに配置できます。
コンポーネントファクトリーはコンポーネントのメインディレクトリのみを検査するため、src/components src/helpersやsrc/containersに含まれるコンポーネントを存在しないSitecoreレンダリングにマッピングしようとはしません。