単一ページアプリケーション(SPA)により、Web サイトのユーザーに魅力的なエクスペリエンスを提供することができます。開発者は SPA フレームワークを使用してサイトを構築したいと考え、作成者はそうして構築されたサイトのコンテンツを AEM 内でシームレスに編集したいと考えています。
この記事では、フロントエンド開発者が AEM 向けの SPA を開発する際に考慮すべき重要な問題を紹介し、SPA を AEM にデプロイする際に関する AEM のアーキテクチャの概要を説明します。
SPA エディターは、SPA フレームワークを基にしたクライアントサイドレンダリング(React など)が必要なプロジェクトで有効なソリューションです。
AEM で単一ページアプリケーションを開発する場合、フロントエンド開発者は SPA を作成する際に標準的なベストプラクティスを順守するものと想定します。次の一般的なベストプラクティスには AEM 固有の原則はほぼなく、フロントエンド開発者がそれに従うことで、SPA は AEM とコンテンツオーサリング機能と共に機能します。
SPA の開発時にこれらの原則を念頭に置いておけば、サポートされるすべての AEM オーサリング機能を有効にしつつ、柔軟性と将来性も可能な限り実現できます。
AEM オーサリング機能をサポートする必要がない場合は、別の SPA 設計モデルを検討する必要が生じる場合があります。
その他のあらゆるコンポーネントを開発する場合と同様に、コンポーネントの移植性を最大限に高めるように設計する必要があります。互換性、柔軟性、保守性を今後も保証するために、コンポーネントの移植性や再利用性に反するパターンは避ける必要があります。
作成する SPA は、移植性が高く、再利用可能なコンポーネントを使用して構築する必要があります。
フロントエンド開発者は、アプリの作成に使用される SPA コンポーネントのライブラリの作成を自分自身が担当していると考える必要があります。フロントエンド開発者は、コンポーネントの内部構造を完全に制御できます。ただし、AEM は常にサイトの構造を所有しています。
つまり、フロントエンド開発者は、コンポーネントのエントリポイントの前後に顧客コンテンツを追加でき、コンポーネント内でサードパーティの呼び出しを行うこともできます。ただし、フロントエンド開発者は、例えばコンポーネントのネスト方法を完全に制御するわけではありません。
SPA では、コンテンツの動的レンダリングのみに依存する必要があります。AEM がコンテンツ構造のすべての子を取得してレンダリングすることは、デフォルトで期待されています。
特定のコンテンツを指す明示的なレンダリングは静的レンダリングと見なされ、サポートされているものの、AEM コンテンツオーサリング機能との互換性はありません。これは移植性の原則に反するものでもあります。
レンダリングと同様に、すべてのルーティングも動的である必要があります。AEM では、SPA が常にルーティングを所有し、AEM がリッスンしてそれに基づいてコンテンツを取得します。
静的なルーティングは移植性の原則に反し、AEM のコンテンツオーサリング機能との互換性がないことから、作成者を制限することになります。例えば、静的ルーティングの場合、コンテンツ作成者はルートの変更やページの変更を希望する場合は、フロントエンド開発者に依頼する必要があります。
AEM プロジェクトでは、 AEM プロジェクトアーキタイプを活用します。このアーキタイプは、React または Angular を使用する SPA プロジェクトをサポートし、SPA SDK を活用します。
AEM での SPA 開発の原則に従えば、SPA はサポートされるすべての AEM コンテンツオーサリング機能と共に機能します。
ただし、これが全く必要でない場合もあります。次の表に、様々なデザインモデルの長所と短所の概要を示します。
設計モデル |
メリット | デメリット |
---|---|---|
AEM は、SPA エディター SDK フレームワークを使用せずにヘッドレスな CMS として使用されます。 | フロントエンド開発者は、アプリを完全に制御できます。 | コンテンツ作成者は、AEM のコンテンツオーサリングエクスペリエンスを活用できません。 コードに静的参照またはルーティングが含まれる場合、コードは移動も再利用もできません。 テンプレートエディターの使用を許可しないので、フロントエンド開発者は JCR を介して編集可能なテンプレートを維持する必要があります。 |
フロントエンド開発者は SPA エディター SDK フレームワークを使用しますが、コンテンツ作成者に対して一部の領域のみを開きます。 | 開発者は、アプリの制限された領域でのみオーサリングを有効にすることで、アプリを管理し続けます。 | コンテンツ作成者は、AEM コンテンツオーサリングエクスペリエンスの限られたセットに制限されます。 コードに静的参照またはルーティングが含まれる場合、移動や再利用性できない問題が発生する可能性があります。 テンプレートエディターの使用を許可しないので、フロントエンド開発者は JCR を介して編集可能なテンプレートを維持する必要があります。 |
このプロジェクトは SPA エディター SDK を十二分に活用し、フロントエンドコンポーネントはライブラリとして開発され、アプリのコンテンツ構造は AEM に委任されます。 | アプリは再利用可能で移動可能です。 コンテンツ作成者は、AEM コンテンツオーサリングエクスペリエンスを使用してアプリを編集できます。 SPA は、テンプレートエディターと互換性があります。 |
開発者は、アプリの構造と AEM に委任されたコンテンツを管理できません。 ただし、開発者は、AEM で作成する予定ではないコンテンツ用にアプリの領域を予約できます。 |
AEM ではすべてのモデルがサポートされていますが、3 番目のモデルを実装することでのみ(つまり AEM で推奨される SPA 開発原則に従うことで)、コンテンツ作成者は SPA のコンテンツをいつもどおりに操作、編集できます。
一般的に、SPA が AEM の SPA 開発原則に従う場合、SPA は AEM で動作し、AEM SPA エディターを使用して編集できます。
既存の SPA を AEM で動作する準備をするには、次の手順に従います。
JS コンポーネントをモジュラー化します。
任意の順序、位置、サイズでレンダリングできるようにします。
SDK が提供するコンテナを使用して、コンポーネントを画面に配置します。
AEM を使用すると、ページと段落のシステムコンポーネントを使用できます。
各 JS コンポーネントに AEM コンポーネントを作成します。
AEM コンポーネントは、ダイアログと JSON の出力を定義します。
フロントエンド開発者が AEM 用の SPA の作成に従事する際の主な仕事は、コンポーネントとその JSON モデルについて合意することです。
AEM 用の SPA を開発する際に、フロントエンド開発者が実行する必要のある手順の概要を次に示します。
コンポーネントと JSON モデルに合意する
フロントエンド開発者とバックエンド AEM 開発者は、必要なコンポーネントとモデルについて合意し、SPA コンポーネントからバックエンドコンポーネントに 1 対 1 で一致させる必要があります。
AEM コンポーネントは、主に編集ダイアログを提供し、コンポーネントモデルを書き出すためにも必要です。
React コンポーネントでは、this.props.cqModel
を介してアクセスする
コンポーネントについて合意が取れ、JSON モデルが設定されると、フロントエンド開発者は SPA を自由に開発でき、this.props.cqModel
を介して JSON モデルに簡単にアクセスできます。
コンポーネントの render()
メソッドを実装する
フロントエンド開発者は、自由に render()
メソッドを実装し、cqModel
プロパティのフィールドを使用できます。これにより、DOM と、ページに挿入される HTML フラグメントが出力されます。これは、React でアプリを作成する標準的な方法です。
MapTo()
を使用してコンポーネントを AEM リソースタイプにマッピングする
マッピングはコンポーネントクラスを格納し、Container
コンポーネントによって内部的に使用され、提供されたリソースタイプに基づいてコンポーネントを取得して動的にインスタンス化します。
これはフロントエンドとバックエンドの間の「接着剤」の役割を果たすので、エディターは、どのコンポーネントが React コンポーネントに対応するのかがわかります。
Page
と ResponsiveGrid
は、基本 Container
を拡張するクラスの好例です。
コンポーネントの EditConfig
をMapTo()
へのパラメーターとして定義する
このパラメーターは、コンポーネントがまだレンダリングされていないか、レンダリングするコンテンツがない場合に、コンポーネントの名前をどのように付けるかをエディターに指示するために必要です。
ページとコンテナに提供されている Container
クラスを拡張する
ページと段落システムは、内部コンポーネントへの委任が期待どおりに機能するように、このクラスを拡張する必要があります。
HTML5 History
API を使用したルーティングソリューションを実装する。
ModelRouter
が有効な場合、pushState
および replaceState
関数を呼び出すと、モデルの欠落したフラグメントを取得するための要求が PageModelManager
にトリガーされます。
ModelRouter
の現在のバージョンでは、Sling Model エントリポイントの実際のリソースパスを指す URL のみ使用できます。バニティ URL やエイリアスの使用はサポートされません。
ModelRouter
は、無効にしたり、正規表現のリストを無視するように設定したりできます。
これらのコードブロックは、React コンポーネントと Angular コンポーネントが、Adobe や AEM に固有のものを必要としていないことを示してします。
この MapTo
helper は、バックエンドとフロントエンドのコンポーネントを一致させる「接着剤」です。
MapTo
の使用法と AEM 向け SPA の構築の概要について詳しくは、選択したフレームワークの概要を参照してください。
開発、オーサリング、公開環境を含む AEM の一般的なアーキテクチャは、SPA を使用する場合でも変更されません。ただし、SPA 開発がこのアーキテクチャにどのように適合しているかを理解することに役立ちます。
ビルド環境
SPA のアプリケーションとコンポーネントのソースは、ここでチェックアウトされます。
AEM オーサー
コンテンツは、AEM オーサー(オーサリング SPA を含む)で作成されます。
オーサリング環境で SPA エディターを使用して SPA を編集する場合の流れは次の通りです。
cq-data
属性を含むページの DOM を構築できるようになります。cq-data
属性を使用すると、エディターが追加のページ情報を読み込んで、コンポーネントで使用する編集設定を把握できるようになります。AEM パブリッシュ
SPA アプリケーションアーティファクト、クライアントライブラリ、コンポーネントなどのオーサリング済みコンテンツおよびコンパイル済みライブラリが、一般向けに公開される場所です。
Dispatcher/CDN
Dispatcher は、サイト訪問者に対する AEM のキャッシュ層の役割を果たします。
AEM 内では、JavaScript のビルドメカニズムを実行したり、JavaScript 自体を実行したりする必要はありません。AEM は、SPA アプリケーションからコンパイルされたアーティファクトのみをホストします。
AEM でのシンプルな SPA の構造と仕組みの概要については、React および Angular 両方の入門ガイドを参照してください。
独自の SPA を作成する手順については、AEM SPA Editor の使用の手引き - WKND イベントチュートリアルを参照してください。
動的モデルとコンポーネントのマッピング、および AEM の SPA 内での動作について詳しくは、SPA の動的モデルとコンポーネントのマッピングの記事を参照してください。
React や Angular 以外のフレームワーク用に AEM の SPA を実装する場合や、AEM 用 SPA SDK の仕組みを詳しく知りたい場合は、SPA ブループリントの記事を参照してください。