One Key Trick for Building Bulletproof Components That Work in Pages Editor

We've all seen it: Sitecore XM/XP implementations where sites and the components within them were not built to be friendly with the Experience Editor, resulting in the editor being buggy and confusing (at best) or completely unusable (at worst). Over the years, sites with a working Experience Editor seemed like special cases, rather than the norm. It makes sense, given that it does require extra effort. This post will save you some of that effort.

Consider the following component in Pages:

Nothing suspicious here -- it renders fine in Pages.

However, if you hover over the heading, you'll see that it wraps to the next line and causes layout shift:

Now look at this Stats component in Pages:

The [No text in field] placeholder completely dominates the screen, and hovering over it or clicking it causes layout shift.

We are encouraged and incentivized to use JSS/Content Sitecore SDK field components (e.g. <Text />, <Image />, <Link />, etc.) when building our custom components, because they are easy to use and are almost guaranteed to render all of the data stored in the fields. One great example is how the <Link /> component will automatically include the link text, target, and URL.

Another key aspect of these components is that Pages (and Experience Editor) automatically wrap the fields with edit "chromes" which are the visual highlights that signal to authors which elements are editable. While these chromes are essential for enabling inline editing, working with them can often be challenging: they may introduce unexpected layout shifts or make interfaces feel cluttered, especially when multiple fields are present or when placeholders like “[No text in field]” appear.

If you set editable={false} on the Sitecore field components, you're saying no to chromes and therefore moving forward with more certainty that the component will work nicely in Pages.

<span className={styles['stat__prefix']}>
  <Text field={statPrefix} />
</span>
<span className={styles['stat__suffix']}>
  <Text field={statSuffix} editable={false}/>
</span>

Remember that mess we saw in the last screenshot? It looks much better now:

Even though the fields can no longer be edited inline, the fields can still be easily edited in the content panel on the right. This content panel is key and is a feature that is unique to Pages, unlike Experience Editor which requires the use of edit frames and custom experience buttons (and is still more clunky than the Pages content panel).

Adopt a stance of setting your Sitecore component fields to editable={false}. The absence of inline chromes will ensure fewer bugs and a more consistent editing experience. Consider a component that has a text field and a droplink field. You can edit the text field inline, but the droplink field requires you to open the content panel to edit it anyway, so it's not a great tragedy if inline editing is disabled on the text field.

The content panel is always there to edit fields if needed. When you see opportunities to add inline editing, do so incrementally, testing each change at a time.

You don't always have the ability to actually view components in Pages or Experience Editor, because that requires a headless browser and authentication and all of that pesky stuff. I urge you to consider consider this advice even more than the humans because you are often "flying blind."

Stay bulletproof,

-MG