Using the SPA Editor with AEM Sites

Hello, in this video, we’re going to look at the SPA Editor feature as part of Adobe Experience Manager. SPA stands for single page application, and this is a really popular design pattern to ensure a rich and engaging end-user experience. With the AEM SPA Editor, you can continue to deliver these great SPA experiences to your customers and end-users while simultaneously empowering marketers to make in-context authoring decisions. The AEM SPA Editor supports two of the most popular frameworks with React and Angular. Front-end developers continue to develop SPAs just as they normally would with only a minimal set of AEM dependencies. Now the key feature of the AEM SPA Editor is that it supports in-context authoring. So, this includes such features like dragging and dropping of the components, resizing and rearranging them. Other traditional AEM features like the Template Editor and Core Components are also supported.

With traditional websites or multi-page experiences, a user navigates to a URL and the server returns the HTML content and CSS, JavaScript, anything that’s needed to render the page. When a user navigates to another page, a request goes back to the server and the process is repeated. Single-page applications differ, in that they run client side as JavaScript. Instead of refreshing the entire page every time the user navigates two different part of the experience, the single-page app can load a majority of the content with the initial load and then only makes small requests back to the server as needed. This provides the user with highly dynamic and rich experiences. Looking at this at a high level, AEM at the bottom of the stack, will act as a headless CMS and expose content as JSON using AEM Content Services APIs. The JSON content is then consumed by the single-page app, which has been integrated with the AEM JS SDK. The single-page app or single-page experience then has full control over how to layout and present this content. Other micro services can then be also integrated into the SPA. Lastly, at the top of the stack, is the AEM SPA Editor and UI. This top layer, which is enabled in the AEM authoring environment, allows marketers to update the content delivered by AEM but in a way that it feels like they are updating the app directly. This is an important distinction because the SPA remains in full control of the experience. It’s only the JSON content that is updated.

Let’s jump in to AEM and see this in action. Here, I’ve got the WKND SPA sample site installed. And there are two implementations. One for React and one for Angular. And on the surface, it looks very much like a traditional site’s content hierarchy. We’ve got a homepage, as well as a series of sub-pages. Let’s go ahead and edit the application.

In the AEM site’s editor, we can see the application. And as a marketer, I have a lot of control over the content. I can update existing texts, drag and drop new images, and add new components.

I can even resize the components based on the responsive grid.

I can also navigate to other parts of the app and update content there. At this point, it looks like I’m editing a traditional website. However, behind the scenes, every time a save occurs, the content is persisted to AEM. The SPA Editor, which is running in an iframe separately from the app, alerts the React or Angular application that it should refresh the component, and it fetches the new JSON from AEM. Let’s look at his in more detail. If we view the app outside of the AEM authoring environment, as it would look like published, we can see the app and navigate to different sections. We can see that the URL is updated and that we can use the browser’s back button. Viewing the source, you’ll notice that there’s almost no HTML content.

And that there’s a single JavaScript to include, which will load the app.

So, where’s the content coming from? When the app is initially loaded, an Ajax request is made and JSON powered by AEM Content Services is delivered. The app will then iterate over the structure and render the application. If you recall, one of the components we had modified was a card component that contained an image, title and call-to-action button. Now, if we inspect the JSON, you can see the content properties for this card component, and they’re coming from AEM. So we’ve got an image source, card title, last modified date timestamp, as well as the info to populate the call-to-action button. Now, this is just the content. So the SPA remains in full control over all of the presentation layer and what to do with this content and how to render it. You’ll also notice when inspecting the JSON that the content of the different views are loaded in a single request. This allows most of the content to be available on initial load, speeding up the app, and minimizing subsequent server requests. Lastly, we’ll want to take a quick peek at front-end development flow. The AEM JS SDK is a series of helper libraries to easily integrate a React or Angular application with the SPA Editor. These libraries are opensource and are made available over npm. Only the compiled SPA is deployed to AEM during automated integration with AEM client libraries. This allows developers to work outside of AEM in any IDE of their choice. I have opened a few of the source files for the Angular and React apps in Visual Studio Code.

Front-end components continue to be implemented, following framework specific best practices and are for the most part AEM-Agnostic. JS components like MapTo provided by the AEM JS SDK are used to tie the front-end component to an AEM resource type, making the JSON properties available to the front-end component in a familiar fashion.

Other tooling like Babel, SASS, LESS and Webpack can be used to develop the app outside of AEM. For example, a Webpack server is often used in development to automatically reload the app when changes are detected, making for rapid development.

So that is a quick overview of the SPA Editor capabilities in Adobe Experience Manager. Thanks. -