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
ルート用のルート データ ファイルを次のように定義できます。
/data/routes/about/en.yml
# name: names the route segment. Should match parent folder name.
name: about
# The root of the layout for this route
placeholders:
# defines the components that belong in the 'main' placeholder
# defining the appname-main placeholder requires a <Placeholder key="appname-main"> component added to the root app component
appname-main:
# Adds a component called 'Heading' to the route in the 'main' placeholder
- componentName: Heading
# Component data can be as complex as a reference to another component (see the reference),
# or as simple as defining field values that the component receives
fields:
# To use fields, they must be defined on the component definition (see below)
# a field consists of a top-level named object and a child value which may be a simple string,
# or something more complex for fields like images
titleField:
value: Page Title
imageField:
value:
src: "/assets/img/logo.png"
alt: Logo
# A component can itself expose placeholders (for example, Heading might expose 'appname-heading-content') that contain more components
# Child placeholders are defined hierarchically under the component that exposes them
placeholders:
appname-heading-content:
- componentName: ContentComponentSample
fields:
# ...
次のサンプルは、同じルート データを JSON で表したものです。
{
"name": "about",
"placeholders": {
"appname-main": [
{
"componentName": "Heading",
"fields": {
"titleField": {
"value": "Page Title"
},
"imageField": {
"value": {
"src": "/assets/img/logo.png",
"alt": "Logo"
}
}
},
"placeholders": {
"content": [
{
"componentName": "ContentComponentSample"
}
]
}
}
]
}
}
コンポーネント コンテンツ
コンポーネント コンテンツは、ルート間でコンポーネントを共有する方法です。コンポーネント コンテンツを使用する一般的なシナリオとしては、lorem ipsum テキストと FPO (配置専用) 画像のみを含む JSS サイトをスケッチし、同じコンポーネントの多数のコピーを保持したくない場合があります。または、複数のルートで共有されているコンテンツがある場合があります。
コンポーネント コンテンツは、ルートと同様のフォルダー構造 (/data/component-content
) で編成され、フォルダーと言語の命名規則も同じです。通常、コンポーネント コンテンツは、それが定義するコンポーネントの名前が付けられたフォルダに格納します。例: /data/component-content/<ComponentName>/id/en.yml
共有コンポーネントの内容は、参照できるように id と name 属性を指定する必要があるということを除いては、ルートに直接追加されたコンポーネントとまったく同じように見えます。ID 値は、JSS アプリケーション全体で一意である必要があります。
/data/component-content/Heading/fpo-heading/en.yml
id: fpo-heading
name: FPO Fake Heading
componentName: Heading
fields:
titleField:
value: Page Title
ルートでの共有コンポーネントの使用は非常に簡単です。コンポーネントをプレースホルダーに追加します。componentName
と name
を指定する代わりに、id
のみを指定します。
/data/routes/en.yml
name: home
placeholders:
appname-main:
- id: fpo-heading
前の例では、fpo-heading
参照はホーム ルート上にあります。すべてのデータがホーム ルート レイアウトに展開されます。
Sitecore にサイトをインポートするときに有効になるコンテンツを参照する別の方法は、コピーです。Sitecore で fpo-heading
のような参照をインポートすると、その参照のすべての使用箇所が単一のコンテンツ アイテムに配置されます。これにより、コンテンツ (著作権など) の共有が容易になります。
複数列のプロモーション、タブ、またはカルーセルで lorem ipsum コンテンツを繰り返すために参照を使用しないでください。インポートすると、最終的なコンテンツは共有されず、一意ではないためです。
コピーによって Sitecore にサイトをインポートするときにコンテンツを参照するには、ID 参照に copy: true
を追加します。
/data/routes/en.yml
name: home
placeholders:
appname-main:
- componentName: Tabs
placeholders:
appname-tabs:
- id: fpo-tab
copy: true
- id: fpo-tab
copy: true
ここで定義したセットアップでは、切断中に 2 つのタブが共有されます。Sitecore にインポートすると、個別に変更できる個別のアイテムになります。
コンポーネント パラメーター
コンポーネントが、データ ソース アイテムのフィールドとして格納されていない値を受け取る必要がある場合があります。このような場合、レンダリング パラメータを使用できます。
コンポーネント props
データのレンダリング パラメーター オブジェクトを公開できます。
{
name: 'my-route',
placeholders: {
jss-main: [
{
componentName: 'my-component',
params: {
paramName: 'paramValue'
}
}
]
}
}
ルート データの param
値は、数値やブール値などの任意の JavaScript データ型として定義できますが、すべての param
値は、コンポーネントによって受信されるときに文字列になります。
コンポーネント コードでは、props.params.paramName
などの、コンポーネントのプロパティで params
オブジェクトにアクセスできます。
マニフェスト生成プロセスの一環として、params データはマニフェストに追加したコンポーネント オブジェクトにマップされます。
コンテンツ
ルートでも共有コンポーネント コンテンツでもないコンテンツ アイテムを定義できます。例には、静的アイテムのコンテンツを含むアイテムや、コンテンツ内のマルチリスト フィールドの共有オプションであるアイテムが含まれます。
コンテンツ アイテムは、次の 2 つの例外を除いて、コンポーネント コンテンツとまったく同じように機能します。
-
componentName
の代わりに、template
を指定します。 -
コンテンツ アイテムの定義は、
/data/content
に格納されます。
ディクショナリ データ
JSS を使用すると、切断された状態で作業しながら多言語アプリケーションを開発できます。多言語アプリケーションの一般的な要件は、フォーム ラベルやグローバル要素などのコンテンツ以外のテキスト要素を翻訳するディクショナリを持つことです。
JSS サンプル アプリケーションでは、/data/dictionary
の下にディクショナリを定義します。 - en.yaml
や es-MX.json
など、言語ごとに単一のファイルが、ディクショナリのキーと値の間の単純なマッピングと共に追加されます。
/data/dictionary/es-MX.yaml
Login: Iniciar sesión
Close: Cerca
LoginFailed: Nombre de usuario y / o contraseña inválido.