Dynamic Model to Component Mapping for SPAs dynamic-model-to-component-mapping-for-spas

CAUTION
AEM 6.4 has reached the end of extended support and this documentation is no longer updated. For further details, see our technical support periods. Find the supported versions here.

This document describes how the dynamic model to component mapping occurs in the Javascript SPA SDK for AEM.

NOTE
The Single-Page Application (SPA) Editor feature requires AEM 6.4 service pack 2 or newer.
The SPA Editor is the recommended solution for projects that require SPA framework based client-side rendering (e.g. React or Angular).

ComponentMapping Module componentmapping-module

The ComponentMapping module is provided as an NPM package to the front-end project. It stores front-end components and provides a way for the Single Page Application to map front-end components to AEM resource types. This enables a dynamic resolution of components when parsing the JSON model of the application.

Each items present in the model contains a :type field that exposes an AEM resource type. When mounted, the front-end component can render itself using the fragment of model it has received from the underlying libraries.

Please refer to the SPA Blueprint document for more information about model parsing and the front-end component access to the model.

Also see the npm package: https://www.npmjs.com/package/@adobe/aem-spa-component-mapping

Model-Driven Single Page Application model-driven-single-page-application

Single Page Applications leveraging the Javascript SPA SDK for AEM are model-driven:

  1. Front-end components register themselves to the Component Mapping Store.

  2. Then the Container, once provided with a model by the Model Provider, iterates over its model content ( :items).

  3. In the case of a page, its children ( :children) first get a component class from the Component Mapping and then instantiate it.

App Initialization app-initialization

Each component is extended with the capabilities of the ModelProvider. Initialization therefore take the following general form:

  1. Each model provider initializes itself and listens for changes made to the piece of model that corresponds to its inner component.

  2. The PageModelManager must be initialized as represented by the initialization flow.

  3. Once stored, the page model manager returns the complete model of the app.

  4. This model is then passed to the front-end root Container component of the application.

  5. Pieces of the model are finally propagated to each individual child component.

app_model_initialization

recommendation-more-help
2315f3f5-cb4a-4530-9999-30c8319c520e