XB week 30: HTML comments

Published on 18 March, 2025

It’s been a while since there was a screenshotless for Experience Builder (XB) week overview, but this is one of those. Solely adding more infrastructure and evolving existing ones.

You may recall that last week, a “Publish” button was introduced that was supposed to be short-lived. It’s still around, but the server-side support for the intended UX did land this week: Ted “tedbow” Bowman and Lee “larowlan” Rowlands expanded XB’s internal HTTP API to be able to publish all auto-saved entities. In a future blog post, you’ll get to see the UX this enables!

Two weeks ago we added the Page content entity type for landing pages. We described the rationale for this more tightly controlled content entity type. We already ensured it integrates with the Metatag module, and this week Matt “mglaman” Glaman landed another step: he added a (media) image base field for SEO purposes.

On the client side, Bálint “balintbrews” Kléri and Ben “bnjmnm” Mullins refactored the foundations of XB’s Redux-integrated field widgets (which allows XB’s semi-real-time previews) into presentational components and behavioral wrappers, enabling those presentational components to be used elsewhere in the UI, not just in field widgets.

Accurate previews thanks to HTML comments

Our intent is to eventually have actual real-time previews with in-place editing wherever possible (see #3453690: [META] Real-time preview: supporting back-end infrastructure for details), which requires knowing where in the DOM which component inputs appear. In Single Directory Components (SDC) terminology: where which props appear.
And before that, something far simpler: where component instances themselves begin and end. Otherwise, XB wouldn’t be able to know what hovered or selected HTML corresponds to which component instance in the XB component tree!

An important step towards landed this week thanks to Lee, Jesse Baker and Dave “longwave” Long: a Twig extension is now wrapping:

  • rendered SDCs in <!-- xb-start-{{UUID}} --> + <!-- xb-end-{{UUID}} --> comments
  • SDC props in <!-- xb-prop-start-{{prop name}} --> + <!-- xb-prop-end-{{prop name}} -->
  • SDC slots in  <!-- xb-slot-start-{{slot name}}--><!-- xb-slot-end-{{slot name}} --> comments.

Why comments? Why not use SDC’s native data-component-id attribute? 🤔

That last question is the easiest one to answer: while SDC’s Twig extension indeed is adding that data- attribute1, this is not reliable, because SDCs are not guaranteed to have an attributes prop, and even if they do, it’s not enforced that it’s applied to the SDC’s outermost tag.2
If XB were to rely on this, it’d result in some SDCs being either incorrectly highlighted by XB’s UI, or even impossible to highlight.

Plus, 4 weeks ago XB introduced the concept of ComponentSource plugins, so we need a mechanism that can be implemented by any source of components, an SDC-only solution is a partial solution.

The intuitive (and naïve) answer might be: “well, just add the necessary wrapping markup!” — but this would break the preview! 😅 The preview MUST NOT use any additional markup: CSS selectors would no longer match, JS (think Drupal.behaviors.*) would have to be made aware of multiple possible structures, and so on.

That’s how we arrive at HTML Comments as the solution outlined by Jesse six months earlier: it can work for any ComponentSource plugin, and it doesn’t interfere with the components’ CSS and JS. And actually … XB does use the naïve but wrong approach of using a wrapper element: we couldn’t wait for all this infrastructure to exist, so now we’ll have to refactor that away.

Fun fact: I used this a decade ago for similar reasons in my renderviz proof-of-concept! 🤓

Grab bag

We noticed that tests are failing on Drupal 11.0. This is because XB added a ComponentSource plugin to support block plugins, and Drupal core only made Block plugins’ settings fully validatable in 11.1! Dave, Lauri “lauriii” Timmanee, Jesse and I solved it  by making XB require not any version of Drupal 11, but Drupal 11.1 or newer, while still retaining support for Drupal 10.4.
That means XB needs to do some backwards compatibility work for Drupal 10.4 support, but when testing against the latest and greatest version of Drupal core, XB takes full advantage of what it offers.

Week 30 was December 2–8, 2024.

  • 1

    It’s adding it in  \Drupal\Core\Template\ComponentsTwigExtension::mergeAdditionalRenderContext().

  • 2

    Pierre “pdureau” Dureau’s research shows that ~87% of the SDCs across a wide range of contributed Drupal themes use the attributes prop. That means that XB relying on this SDC infrastructure would inevitably lead to a frustrating experience with some SDCs “inexplicably” not working in XB.