JSSマニフェスト・データのタイプ

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

このページの翻訳は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.

共有コンポーネントの内容は、ルートに直接追加されたコンポーネントexcept that you must specify an id and a name attribute so it can be referred toとまったく同じです。ID値は、JSSアプリケーション全体で一意である必要があります。

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

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

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

# /data/routes/en.yml

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

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

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

メモ

複数列のプロモーション、タブ、またはカルーセルで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つのタブはwhile disconnectedで共有されます。Sitecoreにインポートすると、それらは個別に変更できる個別のアイテムになります。

コンポーネントパラメータ

コンポーネントが、データ ソース アイテムのフィールドとして保存されていない値を受け取る必要がある場合があります。このような場合は、レンダリング パラメータを使用できます。

レンダリング パラメータ オブジェクトをコンポーネントのpropsデータに公開できます。

{
  name: 'my-route',  
  placeholders: {
    jss-main: [
      {
        componentName: 'my-component',
        params: {
          paramName: 'paramValue'
        }
      }
    ]
  }
}
手記

ルート データのparam値は、numberやBooleanなどの任意のJavaScriptデータ型として定義できますが、コンポーネントが受け取るparam値はすべて文字列です。

コンポーネント コードでは、コンポーネント プロパティのparamsオブジェクト ( props.params.paramNameなど) にアクセスできます。

マニフェスト生成プロセスの一部として、paramsデータはマニフェストに追加したコンポーネントオブジェクトにマッピングされます。

コンテンツ

ルートでも共有コンポーネント・コンテンツでもないコンテンツ・アイテムを定義することができます。たとえば、静的アイテムのコンテンツを含むアイテムや、コンテンツ内のマルチリスト フィールドの共有オプションであるアイテムなどです。

コンテンツアイテムは、次の2つの例外を除いて、コンポーネントコンテンツとまったく同じように機能します。

  • componentNameの代わりに、templateを指定します。

  • コンテンツ・アイテムの定義は、/data/contentに格納します。

辞書データ

JSSを使用すると、切断された状態で作業しながら多言語アプリケーションを開発できます。多言語アプリケーションの一般的な要件は、フォームラベルやグローバル要素などの非コンテンツテキスト要素を翻訳するdictionaryを用意することです。

JSSサンプルアプリケーションでは、ディクショナリを /data/dictionaryで定義します - en.yamles-MX.jsonなどの言語ごとに1つのファイルが追加され、ディクショナリのキーと値の間の単純なマッピングが行われます。

# /data/dictionary/es-MX.yaml

Login: Iniciar sesión
Close: Cerca
LoginFailed: Nombre de usuario y / o contraseña inválido.
この記事を改善するための提案がある場合は、 お知らせください!