AEM 向け SPA の開発

単一ページアプリケーション（SPA）により、Web サイトのユーザーに魅力的なエクスペリエンスを提供することができます。開発者は SPA フレームワークを使用してサイトを構築したいと考え、作成者はそうして構築されたサイトのコンテンツを AEM 内でシームレスに編集したいと考えています。

この記事では、フロントエンド開発者が AEM 向けの SPA を開発する際に考慮すべき重要な問題を紹介し、SPA を AEM にデプロイする際に関する AEM のアーキテクチャの概要を説明します。

AEM 向け SPA 開発原則

AEM で単一ページアプリケーションを開発する場合、フロントエンド開発者は SPA を作成する際に標準的なベストプラクティスを順守するものと想定します。次の一般的なベストプラクティスには AEM 固有の原則はほぼなく、フロントエンド開発者がそれに従うことで、SPA は AEM とコンテンツオーサリング機能と共に機能します。

• 移植性 - 他のコンポーネントと同様に、コンポーネントは可能な限り移動可能な状態で構築する必要があります。SPA は、移動可能で再利用可能なコンポーネントを使用して構築する必要があります。
• AEM を主軸にしたサイト構築 - フロントエンド開発者はコンポーネントを作成し、内部構造を所有しますが、AEM に依存してサイトのコンテンツ構造を定義します。
• 動的レンダリング - すべてのレンダリングは動的である必要があります。
• 動的ルーティング - SPAはルーティングを担当し、AEMはリッスンしてそれに基づいて取得します。どのルーティングも動的である必要があります。

SPA の開発時にこれらの原則を念頭に置いておけば、サポートされるすべての AEM オーサリング機能を有効にしつつ、柔軟性と将来性も可能な限り実現できます。

AEM オーサリング機能をサポートする必要がない場合は、別の SPA 設計モデルを検討する必要が生じる場合があります。

移植性

その他のあらゆるコンポーネントを開発する場合と同様に、コンポーネントの移植性を最大限に高めるように設計する必要があります。互換性、柔軟性、保守性を今後も保証するために、コンポーネントの移植性や再利用性に反するパターンは避ける必要があります。

作成する SPA は、移植性が高く、再利用可能なコンポーネントを使用して構築する必要があります。

AEM を主軸にしたサイト構築

フロントエンド開発者は、アプリの作成に使用される SPA コンポーネントのライブラリの作成を自分自身が担当していると考える必要があります。フロントエンド開発者は、コンポーネントの内部構造を完全に制御できます。ただし、AEM は常にサイトの構造を所有しています。

つまり、フロントエンド開発者は、コンポーネントのエントリポイントの前後に顧客コンテンツを追加でき、コンポーネント内でサードパーティの呼び出しをおこなうこともできます。ただし、フロントエンド開発者は、例えばコンポーネントのネスト方法を完全に制御するわけではありません。

動的レンダリング

SPA では、コンテンツの動的レンダリングのみに依存する必要があります。AEM がコンテンツ構造のすべての子を取得してレンダリングすることは、デフォルトで期待されています。

特定のコンテンツを指す明示的なレンダリングは静的レンダリングと見なされ、サポートされているものの、AEM コンテンツオーサリング機能との互換性はありません。これは移植性の原則に反するものでもあります。

動的ルーティング

レンダリングと同様に、すべてのルーティングも動的である必要があります。AEM では、SPA が常にルーティングを所有し、AEM がリッスンしてそれに基づいてコンテンツを取得します。

静的なルーティングは移植性の原則に反し、AEM のコンテンツオーサリング機能との互換性がないことから、作成者を制限することになります。例えば、静的ルーティングの場合、コンテンツ作成者はルートの変更やページの変更を希望する場合は、フロントエンド開発者に依頼する必要があります。

AEM プロジェクトアーキタイプ

AEM プロジェクトでは、 AEM プロジェクトアーキタイプを活用します。このアーキタイプは、React または Angular を使用する SPA プロジェクトをサポートし、SPA SDK を活用します。

SPA デザインモデル

AEM での SPA 開発の原則に従えば、SPA はサポートされるすべての AEM コンテンツオーサリング機能と共に機能します。

ただし、これが全く必要でない場合もあります。次の表に、様々なデザインモデルの長所と短所の概要を示します。

既存の SPA から AEM への移行

一般的に、SPA が AEM の SPA 開発原則に従う場合、SPA は AEM で動作し、AEM SPA エディターを使用して編集できます。

既存の SPA を AEM で動作する準備をするには、次の手順に従います。

1. JS コンポーネントをモジュラー化します。

   任意の順序、位置、サイズでレンダリングできるようにします。

2. SDK が提供するコンテナを使用して、コンポーネントを画面に配置します。

   AEMは、使用するページと段落のシステムコンポーネントを提供します。

3. 各 JS コンポーネントに AEM コンポーネントを作成します。

   AEMコンポーネントは、ダイアログとJSON出力を定義します。

フロントエンド開発者向けの説明

フロントエンド開発者にAEM向けのSPAを作成させる主な作業は、コンポーネントとそのJSONモデルについて合意することです。

AEM 用の SPA を開発する際に、フロントエンド開発者が実行する必要のある手順の概要を次に示します。

1. コンポーネントと JSON モデルに合意する

   フロントエンド開発者とバックエンド AEM 開発者は、必要なコンポーネントとモデルについて合意し、SPA コンポーネントからバックエンドコンポーネントに 1 対 1 で一致させる必要があります。

   AEM コンポーネントは、主に編集ダイアログを提供し、コンポーネントモデルを書き出すためにも必要です。

2. React コンポーネントでは、this.props.cqModel を介してアクセスする

   コンポーネントについて合意が取れ、JSON モデルが設定されると、フロントエンド開発者は SPA を自由に開発でき、this.props.cqModel を介して JSON モデルに簡単にアクセスできます。

3. コンポーネントの render() メソッドを実装する

   フロントエンド開発者は、必要に応じてrender()メソッドを実装し、cqModelプロパティのフィールドを使用できます。 これにより、DOM と、ページに挿入される HTML フラグメントが出力されます。これは、React でアプリを作成する標準的な方法です。

4. MapTo() を使用してコンポーネントを AEM リソースタイプにマッピングする

   マッピングはコンポーネントクラスを格納し、Container コンポーネントによって内部的に使用され、提供されたリソースタイプに基づいてコンポーネントを取得して動的にインスタンス化します。

   これはフロントエンドとバックエンドの間の「接着剤」の役割を果たすので、エディターは、どのコンポーネントが React コンポーネントに対応するのかがわかります。

   Page と ResponsiveGrid は、基本 Container を拡張するクラスの好例です。

5. コンポーネントの EditConfig をMapTo() へのパラメーターとして定義する

   このパラメーターは、コンポーネントがまだレンダリングされていないか、レンダリングするコンテンツがない場合に、コンポーネントの名前をどのように付けるかをエディターに指示するために必要です。

6. ページとコンテナに提供されている Container クラスを拡張する

   ページと段落システムは、内部コンポーネントへの委任が期待どおりに機能するように、このクラスを拡張する必要があります。

7. HTML5 History API を使用したルーティングソリューションを実装する。

   ModelRouter が有効な場合、pushState および replaceState 関数を呼び出すと、モデルの欠落したフラグメントを取得するための要求が PageModelManager にトリガーされます。

   ModelRouter の現在のバージョンでは、Sling Model エントリポイントの実際のリソースパスを指す URL のみ使用できます。バニティ URL やエイリアスの使用はサポートされません。

   ModelRouter は、無効にしたり、正規表現のリストを無視するように設定したりできます。

AEM 非依存

これらのコードブロックは、ReactコンポーネントとAngularコンポーネントが、AdobeやAEM固有のものを必要としないことを示します。

• JavaScript コンポーネント内にあるものはすべて、AEM 非依存です。
• AEM に固有なことは、JS コンポーネントを MapTo ヘルパーを使用して AEM コンポーネントにマッピングする必要がある点です。

MapTo ヘルパーは、バックエンドとフロントエンドのコンポーネントを一致させる「接着剤」です。

• これは、JS コンテナ（または JS 段落システム）に、JSON に存在する各コンポーネントのレンダリングは、どの JS コンポーネントが関与するのかを伝えるものです。
• JS コンポーネントでレンダリングされる HTML に HTML データ属性が追加されるので、SPA エディターは、コンポーネントの編集時に作成者に表示するダイアログボックスを把握できます。

MapTo の使用法と AEM 向け SPA の構築の概要について詳しくは、選択したフレームワークの概要を参照してください。

• AEMでのSPAの概要 — React
• AEMでのSPAの概要 —Angular

AEM のアーキテクチャと SPA

開発、オーサリング、公開環境を含む AEM の一般的なアーキテクチャは、SPA を使用する場合でも変更されません。ただし、SPA 開発がこのアーキテクチャにどのように適合しているかを理解することに役立ちます。

• ビルド環境

  SPA のアプリケーションとコンポーネントのソースは、ここでチェックアウトされます。

  • NPM clientlib ジェネレーターは、SPA プロジェクトからクライアントライブラリを作成します。
  • ライブラリは Maven によって取得され、AEM オーサーのコンポーネントと共に、Maven Build プラグインによってデプロイされます。

• AEM オーサー

  コンテンツは、AEM オーサー（オーサリング SPA を含む）で作成されます。

  オーサリング環境で SPA エディターを使用して SPA を編集する場合の流れは次の通りです。

  1. SPA は外部の HTML をリクエストします。
  2. CSS が読み込まれます。
  3. SPA アプリケーションの JavaScript が読み込まれます。
  4. SPA アプリケーションを実行すると、JSON がリクエストされ、アプリが cq-data 属性を含むページの DOM を構築できるようになります。
  5. この cq-data 属性を使用すると、エディターが追加のページ情報を読み込んで、コンポーネントで使用する編集設定を把握できるようになります。

• AEM パブリッシュ

  SPA アプリケーションアーティファクト、クライアントライブラリ、コンポーネントなどのオーサリング済みコンテンツおよびコンパイル済みライブラリが、一般向けに公開される場所です。

• Dispatcher／CDN

  Dispatcher は、サイト訪問者に対する AEM のキャッシュ層の役割を果たします。

  • リクエストは、AEM オーサーでの処理と同様に処理されますが、ページ情報のリクエストはありません。ページ情報はエディターのみに必要とされる情報だからです。
  • JavaScript、CSS、JSON および HTML がキャッシュされ、配信が高速になるようにページが最適化されます。

次の手順

AEMのシンプルなSPAの構造と仕組みの概要については、ReactとAngularの両方の入門ガイドを参照してください。

独自のSPAを作成する手順ガイドについては、「 AEM SPA Editor使用の手引き — WKNDイベントチュートリアル 」を参照してください。

動的モデルとコンポーネントのマッピングおよびAEMのSPA内での動作方法について詳しくは、SPA🔗の動的モデルとコンポーネントのマッピングの記事を参照してください。

ReactやAngular以外のフレームワーク用にAEMにSPAを実装する場合や、AEM用SPA SDKの仕組みを深く掘り下げたい場合は、SPA Blueprintの記事を参照してください。