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
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!
Nice, Informative
Hello Ryan,
Amazing job! I have some questions:
Did you use an external API/Tool to compile the React Components?
What was the most complex component that you developed?
Best Regards,
Rafael
Hey Rafael,
Thanks for the question – we actually leveraged the Nashorn Javascript engine within AEM to compile on the server side. We developed a multi-threaded solution to compile just the externalized templates, while compiling the rest of the application using grunt at build time. That being said, if you had an external API server, this would work even better, as you can reduce the load on your AEM servers.
I would say the most complex component of this exercise was between that multi-threaded compiling service and the dynamic client library generation based on the output.
Cheers,
Ryan
Amazing Job. If you could share the solution with sample package & diagram would be helpful.
Ryan, is there a way I can get in communication with you. I would like to talk a bit more about the React/AEM approach
Thanks Jay! We’re working on a more technical deep dive in a future blog series which will have this information – keep your eyes peeled!
@Dave,
Please reach out to us here and we’d be happy to set up a discussion:
https://www.perficient.com/contact
Thanks!