JSS マニフェスト データの型

Version: 20.x
日本語翻訳に関する免責事項

このページの翻訳は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 ルート用のルート データ ファイルを次のように定義できます。

RequestResponse
/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 で表したものです。

RequestResponse
{
  "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

共有コンポーネントの内容は、参照できるように idname 属性を指定する必要があるということを除いては、ルートに直接追加されたコンポーネントとまったく同じように見えます。ID 値は、JSS アプリケーション全体で一意である必要があります。

RequestResponse
/data/component-content/Heading/fpo-heading/en.yml

id: fpo-heading
name: FPO Fake Heading
componentName: Heading
fields:
  titleField:
    value: Page Title

ルートでの共有コンポーネントの使用は非常に簡単です。コンポーネントをプレースホルダーに追加します。componentNamename を指定する代わりに、id のみを指定します。

RequestResponse
/data/routes/en.yml

name: home
placeholders:
  appname-main:
  - id: fpo-heading

前の例では、fpo-heading 参照はホーム ルート上にあります。すべてのデータがホーム ルート レイアウトに展開されます。

Sitecore にサイトをインポートするときに有効になるコンテンツを参照する別の方法は、コピーです。Sitecore で fpo-heading のような参照をインポートすると、その参照のすべての使用箇所が単一のコンテンツ アイテムに配置されます。これにより、コンテンツ (著作権など) の共有が容易になります。

注記

複数列のプロモーション、タブ、またはカルーセルで lorem ipsum コンテンツを繰り返すために参照を使用しないでください。インポートすると、最終的なコンテンツは共有されず、一意ではないためです。

コピーによって Sitecore にサイトをインポートするときにコンテンツを参照するには、ID 参照に copy: true を追加します。

RequestResponse
/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 データのレンダリング パラメーター オブジェクトを公開できます。

RequestResponse
{
  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.yamles-MX.json など、言語ごとに単一のファイルが、ディクショナリのキーと値の間の単純なマッピングと共に追加されます。

RequestResponse
/data/dictionary/es-MX.yaml

Login: Iniciar sesión
Close: Cerca
LoginFailed: Nombre de usuario y / o contraseña inválido.

何かフィードバックはありますか?

この記事を改善するための提案がある場合は、