JSSマニフェスト・データのタイプ
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
Sitecoreから切断して作業しているときにアプリケーションのコンテンツをモックするには、JSSアプリケーションのdataディレクトリにあるJSONファイルまたはYAMLファイルに複数の種類のデータを定義できます。データの場所は、変更可能な規則です。
実際のマニフェスト定義 (データ ファイルから派生した定義を含む) は、/sitecore/definitions/*.sitecore.jsにあります。これらのマニフェスト定義ファイルは、ヘルパーライブラリを使用してYAML/JSONファイルをクロールし、マニフェストオブジェクトに追加します。一部のマニフェストアイテム、コンポーネント、およびプレースホルダーは、通常 、JS APIを直接使用して定義されます。
JSSは、dataフォルダーからYAMLまたはJSONマニフェスト データ ファイルを読み取り、マニフェストを生成するJavaScript APIに追加することでマニフェストを生成します。したがって、必要に応じて、JSONファイルまたはYAMLファイルを直接JS API呼び出しに置き換えることができます。
データ・アイテムに明示的なIDを設定する場合は、インポート・プロセスでアイテムIDがどのように処理されるかに関心があるかもしれません。
ルート
最小ルート定義には、name (ルート セグメントの構築に使用) が含まれています。ほとんどのルートでは、placeholdersも定義し、フロントエンドコンポーネントのセットと、同じ名前のコンポーネント内に配置されJSS Placeholderデータを定義します。
サンプル アプリでは、ルートは /data/routes/path-to-route/language.{yaml|yml|json}で定義されています。たとえば、/data/routes/en.ymlは英語の / ルートのルートデータ、/data/routes/about/es-MX.ymlはスペイン語(メキシコ)の /aboutルートのデータです。
ルートファイルの構造
ルート ファイルでは非常に高度な機能を使用できますが、定義が非常に簡単である場合もあります。たとえば、YAMLを使用して、aboutルートのルート データ ファイルを次のように定義できます。
次のサンプルは、同じルート データをJSONで表しています。
コンポーネントの内容
コンポーネント コンテンツは、ルート間でコンポーネントを共有する方法です。コンポーネント コンテンツを使用する一般的なシナリオは、lorem ipsumテキストとFPO (配置専用) イメージのみを使用してJSSサイトをスケッチし、同じコンポーネントのコピーを多数保持したくない場合です。または、複数のルートで共有されているコンテンツがあります。
コンポーネント コンテンツは、ルート (/data/component-content) と同様のフォルダー構造で編成され、フォルダーと言語の命名規則は同じです。従来、コンポーネントのコンテンツは、定義するコンポーネントの名前が付けられたフォルダの下に格納します。たとえば、/data/component-content/<ComponentName>/id/en.yml.
共有コンポーネントの内容は、ルートに直接追加されたコンポーネントexcept that you must specify an id and a name attribute so it can be referred toとまったく同じです。ID値は、JSSアプリケーション全体で一意である必要があります。
ルート上での共有コンポーネントの使用は非常に簡単で、プレースホルダーにコンポーネントを追加します。 componentNameとnameを指定する代わりに、次のように指定しますonly the id。
前の例では、fpo-heading参照はホームルート上にあります。そのすべてのデータがホームルートレイアウトに展開されます。
サイトをSitecoreにインポートするときに有効になるコンテンツを参照する別の方法は、コピーです。 fpo-headingのような参照をSitecoreでインポートすると、その参照のすべての使用箇所が1つのコンテンツアイテムに配置されます。コンテンツ(著作権など)の共有を容易にします。
複数列のプロモーション、タブ、またはカルーセルでlorem ipsumコンテンツを繰り返すために参照を使用しないでください。これは、インポート時に最終的なコンテンツが共有されず、一意ではないためです。
コピーによってサイトをSitecoreにインポートするときにコンテンツを参照するには、ID参照にcopy: trueを追加するだけです。
ここで定義した設定では、2つのタブはwhile disconnectedで共有されます。Sitecoreにインポートすると、それらは個別に変更できる個別のアイテムになります。
コンポーネントパラメータ
コンポーネントが、データ ソース アイテムのフィールドとして保存されていない値を受け取る必要がある場合があります。このような場合は、レンダリング パラメータを使用できます。
レンダリング パラメータ オブジェクトをコンポーネントのpropsデータに公開できます。
ルート データのparam値は、numberやBooleanなどの任意のJavaScriptデータ型として定義できますが、コンポーネントが受け取るparam値はすべて文字列です。
コンポーネント コードでは、コンポーネント プロパティのparamsオブジェクト ( props.params.paramNameなど) にアクセスできます。
マニフェスト生成プロセスの一部として、paramsデータはマニフェストに追加したコンポーネントオブジェクトにマッピングされます。
コンテンツ
ルートでも共有コンポーネント・コンテンツでもないコンテンツ・アイテムを定義することができます。たとえば、静的アイテムのコンテンツを含むアイテムや、コンテンツ内のマルチリスト フィールドの共有オプションであるアイテムなどです。
コンテンツアイテムは、次の2つの例外を除いて、コンポーネントコンテンツとまったく同じように機能します。
-
componentNameの代わりに、templateを指定します。
-
コンテンツ・アイテムの定義は、/data/contentに格納します。
辞書データ
JSSを使用すると、切断された状態で作業しながら多言語アプリケーションを開発できます。多言語アプリケーションの一般的な要件は、フォームラベルやグローバル要素などの非コンテンツテキスト要素を翻訳するdictionaryを用意することです。
JSSサンプルアプリケーションでは、ディクショナリを /data/dictionaryで定義します - en.yamlやes-MX.jsonなどの言語ごとに1つのファイルが追加され、ディクショナリのキーと値の間の単純なマッピングが行われます。