The AEM Single Page Editor enables you to modify editable SPA (Single Page Application) content from within AEM. It primarily renders SPA on the client-side and retrieves most or all content in a single page load. One of the advantages of this approach is that it can load additional resources asynchronously as needed, based on user interaction. Its net effect includes tremendous bandwidth savings and vastly improved page refresh speed. SPA usage minimizes delays by reducing calls and dependencies on a server.
The Evolution of AEM-SPA Integration
Initially, AEM took a headless SPA approach, wherein the content was managed through ‘Content Fragments’ and consumed through headless GraphQL APIs. This approach allowed frontend developers to have complete control over the application but didn’t allow the authors to leverage AEM’s content authoring experience. The authors couldn’t use the template editor and frontend developers maintained editable templates via JCR (Java Content Repository).
The advent of SPA version 1.0 integrated SPA directly into AEM. This version fully leverages the SPA Editor SDK, allowing content authors access to AEM’s content authoring experience. Here, the apps are reusable and portable and wire the content structure into AEM. More recently, Adobe introduced Remote SPA 2.0, which is hosted outside of AEM. This arrangement allows developers to maintain control over apps by only enabling authoring in selected areas.
Let’s look at how you might put all of this together.
Remote SPA 2. gives you complete control of the SPA application. Under normal circumstances, content authors are restricted to AEM’s limited set of content authoring tools. SPA Editor 2.0 can enable direct in-content editing for specific areas or snippets in the app.
In Image 2, you can see SPA hosted outside of AEM. Here, the developer controls the app by enabling authoring rights in selected application areas. In Adobe documentation, it is called ‘in-context editable spots.’ AEM content authors are free to produce content but only for editable regions.
The first step is to decide upon components and their JSON model. Conduct a one-to-one match between frontend SPA app components and backend components.
Then, define access to the model and use the render() method. The frontend developer can access the JSON model via this.props.cqModel. Use the cqModel property in the render() method to output the appropriate DOM and HTML fragments.
Map the component to its associated AEM component using MapTo(). This technique perfectly glues the frontend and backend, giving a clear picture to the editor of which components the React components correspond. Here’s how that might look in React and Angular:
You can improve performance by using persistent GraphQL queries, which can be easily indexed using Lucene indexes.
SPA 2.0 Benefits
There are numerous benefits to using the SPA 2.0 solution above. Some of them include:
Additionally, SPA 2.0 app supports modern web and headless delivery. It retrieves the content in a single page load, significantly improving the user experience. Using SPA 2.0 results in faster execution, high performance, and better content management.
We have successfully used Remote SPA 2.0 to integrate React and Angular apps into a number of customers’ AEM implementations.
In our experience, the separation between frontend and backend development greatly facilitates rapid development and gives frontend teams the freedom they need for proper SPA development. A further benefit is vastly improved page load time and page refresh speed.