How to manage content for single-page applications

Single-page applications (SPAs) are web applications or websites that can interact with the user dynamically by rewriting the current page, rather than loading new pages from a server.

The purpose is to avoid interruptions and secure a smooth user experience between successive pages, making the website act more like an app.

Simultaneously with the influx of SPAs in the world of digital experiences there is a parallel newcomer, namely headless CMS. This is essentially a database with APIs to deliver content to any channel.

It’s not difficult to see how single-page apps and headless CMS fit neatly together: the great user experience, clean architecture, and flexible framework of SPAs, coupled with the content/presentation separation of headless.

However, not everything is a bed of roses with single-page apps and headless—especially where the content editors are concerned. Let’s take a look at the challenges and the proposed solutions.

Be sure to choose the right CMS with our handy checklist:

Challenges with SPAs and headless

Inherent in many first generation headless CMSs is the lack of a preview. Conversely, the single-page applications that are built with a headless architecture face the very same challenge.

Content editors are used to work in platforms that show them the end result immediately, either in a separate preview or in the editor tool itself.

Also, a traditional CMS makes it easy for editors to see the content structure of their given website or app, while a headless CMS is just a “free floating” database of contents where the editors fill in forms that are used to populate content fields. The same principle goes for page editing and structure management.

SPAs and headless CMS are primarily developer driven. The decoupling between the content layer and the presentation layer makes for more fun and agility for developers, but poses a challenge for content editors. This is due to first-gen headless limits to what editors can do and customize within the platform.

See also: How to build a fast and modern site with Next.js and headless CMS »

The developer first approach actually leads to more hard coding from the developers, and editors are more dependent than ever on what the devs have taken into account beforehand.

There are possibilities for a lot of hard coded custom switches and complex configuration, but this makes the platform more advanced and cumbersome than necessary.

One final challenge to mention with the SPA/headless architecture is image handling. Whereas another type of CMS can automatize several image editing functions, this is not as easy in a headless environment, due to the separation of content and presentation (not to mention that the content may be presented in wildly different channels).

This leads to the editors constantly managing different image sizes and cropping, which can be a headache.

Overcoming the challenges

Solving previews

As for previews, a best practice is for the developers to set up a standard preview, even though it might not take into account what the presentation will look like on every channel you operate.

Choose exactly how the content will appear in a preview, be aware of the differences with other channels, and build a template for how you would like it to look—essentially what makes the most sense to you. Again, remember that this preview isn’t necessarily identical to how it will look in a SPA.

Solving visual page editing

When it comes to page editing, the best solution for you will most likely be a next-generation headless CMS, which offers all the advantages of a headless CMS, but with some added benefits.

With a next-gen headless model you can deliver the structured data to your visual page editor, letting content editors work in a familiar and user-friendly environment.

Don’t miss: Why choose Enonic's headless CMS when building a Next.js website »

SPA and traditional features

Is it possible to combine a SPA with features of a traditional CMS with a next-gen headless solution? If some part of the app needs a landing page or traditional content, you can combine the app with server side rendered content.

While SPAs and headless certainly is a developer driven framework, you should in any case facilitate cooperation between editor and developer. This ensures flexibility in the CMS: together you should make ground rules for structuring the content, thus making it easier for a content editor to get the job done.

As an example, if the solution supports adding switches, add them where it makes sense, without overloading the amount of possibilities. Similarly, establish relations between content and content types—ensuring a tidy and logical system.

Finally, your CMS should in any case support image handling. This includes focal point and the ability for the developer to define what version of an image that goes where.

Conclusion

Make sure you have a flexible platform to deliver an editor friendly platform for delivering single-page applications.

Headless goes as hand in glove with SPAs, but as a next generation headless CMS supports both headless (delighting your developers) and traditional CMS features (delighting your editors), it might be the right solution for you.

First published 8 May 2019, updated 26 September 2022.