Approach Overview: Compiling and Authoring React Applications in AEM

The Adobe Experience Manager (AEM) platform allows for a great level of customizability – there can be endless unique implementations. This level of customization will continue to increase given Adobe’s frequent updates in integrations and emerging technologies. With the surge in single-page application (SPA) designs, JavaScript frameworks like React, Angular, and Handlebars are now some of the most common front-end integrations – and because AEM currently only minimally supports a few select technologies above, the implementation strategies have differed vastly.  Despite the differences, one thing that nearly all integrations have in common is that author-able content is consumed on the browser side, through a JSON request.

Our Project

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

For a recent project, my team received requirements for in-line editing for a React application supporting multi-site, regionalization, and localization. Now, off the cuff, that may not sound too ground-breaking. As I mentioned, many implementations leverage SPA frameworks. However, in the majority of implementations, this is developed as a singular AEM component in which every author-able field is configured. The result of this setup is a large and confusing authoring experience, without a decent way to preview changes.
In a traditional AEM setup, there are several pages. Each page would have many components with an associated HTML template that can be populated with authored properties. In this scenario, the author would be able to edit fields in context and immediately see their changes reflected on the screen.

An Innovative Solution: Using React Applications in AEM

This project had requirements to support in-context editing of React-based components. It also needed to allow for drag-and-drop of React (and out-of-the-box) components to dynamically create an SPA. The difficulty is that in single-page applications the end result of a component is not an HTML fragment, it’s a JavaScript library. To allow for this, we designed a development pattern to allow the developers to split the application into smaller component pieces, aligning to AEM components. In React, this meant we would pre-compile the meat of the application, and then expose “Externalized Templates” which we could compile in real time for the componential pieces, as well as the application routing.
Fortunately, in the case of React, we can also compile a standard HTML fragment. In order to support any standard HTML components, we can compile them the same way as React-based externalized templates. This translated into AEM Authoring by having pages for each “view” where authors would create pages exactly as if they were out of the box. Using the externalized templates, we could identify the portions of the page which mapped into components and ensure the authoring UX was properly aligned. Given this, an author would not be able to tell which aspects of the page were React and which were out-of-the-box AEM components.

The Final Result

Once we hit publish the root level page, and associated compiled JavaScript library are activated to the AEM Publisher. The view pages required for authoring have no need to be exposed to the outside world and therefore are not included in the workflow. This tight integration allowed the client to maintain a React-based development team able to test and develop outside of AEM. It also allowed them to maintain authoring user experience.
Do you have any implementation tips within AEM? We would love to hear about them!