AEM SPA
Single page applications (SPAs) can offer compelling experiences
for website users. By being faster, fluid, and more like a native application
SPA becomes a very attractive experience, developers want to be
able to build sites using SPA frameworks and authors want to seamlessly edit
content within AEM for a site built using such frameworks.
The SPA Editor offers a comprehensive solution for supporting
SPAs within AEM.
When an SPA is built to leverage the AEM SPA
Editor, the content author notices no difference when editing and creating
content.
Important Points:
·
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 (React or Angular).
·
All SPA projects on AEM should be based on the Maven Archetype for SPA Starter Kit.
How SPA is different?
A single-page
application (SPA) differs from a conventional page is that it is rendered
client-side and is primarily Javascript-driven,
relying on Ajax calls to load data and dynamically update the page.
This reduces the need for
page refreshes and presents an experience to the user that is seamless,
fast, and feels more like a native app experience.
(Sequential web page) (Single Page
Application)
In a traditional, sequential web page, only
the data needed for the immediate page is loaded. This means that when the
visitor moves to another page, the server is called for the additional
resources.
Any SPA project on AEM
should leverage the Maven
Archetype for SPA Starter Kit.
AEM has provided sample
SPA Website “we-retail-journal” below
is the link:
https://github.com/adobe/aem-sample-we-retail-journal
You can directly
download and build this project using command
“mvn clean install –PautoInstallPackage”
You can see the your
single page Application working
Project Structure in AEM
Guidelines for SPA
development in AEM
Developing single page
applications on AEM assumes that the front-end developer observes standard best
practices when creating an SPA.
·
*Portability* - As with any components, the components
should be built to be as portable as possible. The SPA should be built with
portable and reusable components.
·
*AEM Drives Site Structure* - The front end developer creates components
and owns their internal structure, but relies on AEM to define the content
structure of the site.
·
*Dynamic Rendering* - All rendering should be dynamic.
·
*Dynamic Routing* - The SPA is responsible for the routing and
AEM listens to it and fetches based on it. Any routing should be dynamic as
well.
If you keep these
principles in mind as you develop your SPA, it will be as flexible and supports
AEM authoring functionality.
For further details
about SPA development on AEM including guidelines, walkthroughs, best practices
and examples go to https://adobe.com/go/aem-dev-spa.
Deep dive
into AEM SPA
The basic concept of SPA
is to map a SPA Component to an AEM Component. AEM components, runs on
server-side, which exports content in the form of JSON. The JSON content is
consumed by the SPA, running on client-side in the browser. A 1:1 mapping
between SPA components and an AEM component is created.
To build for AEM, the
SPA project is compiled and automatically included in the AEM project.
Standard AEM Packages
used to deploy the SPA into AEM.
SPA development iterations
occur independently of AEM. When the SPA is ready to be deployed into AEM the
following high-level steps take place (as illustrated above).
·
The SPA project's aem-clientlib-generator embeds
the compiled SPA as an AEM Client Library in the AEM project.
·
The AEM project generates an AEM package, including the compiled
SPA, plus any other supporting AEM code.
No comments:
Post a Comment