The AEM Single Page Editor enables you to modify editable SPA (Single Page Application) content from within AEM. The SPA is primarily rendered client-side and retrieves most or all content in a single page load. The advantage of this approach is that additional resources can be loaded asynchronously as needed based on user interaction. The net effect is tremendous bandwidth savings and vastly improved page refresh speed. Using an SPA minimizes delays by reducing calls and dependencies on a server. The Evolution of AEM-SPA Integration Initially, AEM took a headless SPA approach. Content was managed through ‘Content Fragments’, and consumed through headless GraphQL APIs. The advantage of this approach is that the front-end developer has full control over the application. However, the disadvantage is that authors cannot leverage AEM’s content authoring experience. Authors cannot use the template editor, and front-end developers must maintain editable templates via JCR (Java Content Repository). With the advent of SPA version 1.0, SPA is integrated directly into AEM. This version fully leverages the SPA Editor SDK, allowing content authors access to AEM’s content authoring experience. The app is reusable and portable, and the content structure is wired into the AEM. More recently, Adobe introduced Remote SPA 2.0. In this version, the SPA is hosted outside of AEM. This arrangement allows the developer to maintain control over the app by only enabling authoring in selected areas. Let’s now look at how you might put all of this together. Solution Overview Using Remote SPA 2.0, you keep complete control of the SPA application. Under normal circumstances, content authors are restricted to AEM’s limited set of content authoring tools. With the SPA Editor 2.0, direct in-content editing to specific areas or snippets in the app can be enabled. In Image 2, you can see that SPA is hosted outside of AEM. The developer controls the app by enabling authoring rights in selected application areas. This is referred to in the Adobe documentation as ‘in-context editable spots.’ AEM content authors are free to produce content but only for the editable regions. Solution Details The first step is to decide upon components and their JSON model. There will be a one-to-one match between the front-end SPA app components and the back-end components. You then need to define access to the model and use the render() method. The front-end 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. You would then map the component to its associated AEM component using MapTo(). This technique serves as the “glue” between the front-end and back-end, so the editor knows to which components the React components correspond. Here’s how that might look in React and AngularJS: 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. Here are just a few: More focus on content creation
With the SPA 2.0 app, you can edit content using in-context editing, leveraging AEM’s rich experience management suite. The same user experience exists in the author and publisher AEM environments. You can also perform in-line image editing, something that significantly speeds up the content creation process. You can apply the style system to gain additional flexibility, which enables contextual component layout management. Front-end framework agnostic
When using the SPA 2.0 app with AEM, the front-end developer gets complete control over the app with minimal AEM development. You can also mix front-end components with AEM SPA-supported components. This facilitates rapid development and keeps the content authoring and development strategies separated. Front-end developers can continue to extend or add new features to the app using the latest features supported by the front-end framework. Easy to maintain
The SPA 2.0 app is easy to upgrade and maintain. This is because authorable content and its hierarchy are maintained inside AEM. In contrast, most of the development happens outside AEM. The separation between the front-end and back-end reduces complexity and provides a decoupled system, making app development even more straightforward. Another benefit is that the SPA 2.0 app supports modern web and headless delivery. Users experience improved performance as content is retrieved once in a single page load. Using SPA 2.0 results in faster execution, high performance, and better content management. Conclusion We have successfully used Remote SPA 2.0 to integrate ReactJS and AngularJS apps into a number of customers’ AEM implementations. In our experience, the separation between front-end and back-end development greatly facilitates rapid development and gives the front-end teams the freedom they need for proper SPA development. A further benefit is greatly improved page load time and page refresh speed.