XB week 13: location, location & OpenAPI

The first prominent leap forward this week was built by Harumi “hooroomoo” Jang: they added the ability to Experience Builder (XB) to first pick the location to add a component to, and then pick the component, rather than only the other way around:

Clearly, it’s important to support both paths towards placing a component!

Great news: this week, Bálint “balintbrews” Kléri joined the team working on XB full-time :) Satisfyingly, he landed an improvement that he started working on as a volunteer contributor: #3458535: Middle click + drag doesn’t work correctly if middle click is inside preview iframe.

Utkarsh “utkarsh_33”, syeda-farheen, Harumi and Jesse “jessebaker” Baker fixed the undo/redo functionality and added end-to-end tests, ensuring that XB cannot regress anymore on that essential functionality.

Ben “bnjmnm” Mullins and I collaborated to overhaul XB’s all-props test-only Single-Directory Component (SDC), whose purpose is solely to exercise the full spectrum of prop shapes (JSON schemas) that SDC can use:

Last week, we landed component previews, and that was a big leap forward! We firmly believe in rapid iteration, and landing something as soon as it’s at least partially usable, rather than polishing it to perfection — for a mature codebase like Drupal core that makes sense, but not for something that is still in its infancy, like XB. So, unsurprisingly, we found an (obvious) bug: the preview caused styles to bleed:

Jesse, Utkarsh and Gaurav “gauravvvv” used shadow DOM to properly encapsulate this.

OpenAPI: constantly keeping front-end and back-end work in sync

Back during week 3, Lee “larowlan” Rowlands opened an issue to create an OpenAPI spec for the (then) mock HTTP responses. Back then, the client (React, JS) and server (PHP, Drupal module) were being developed completely independently. Because things were still moving so rapidly back then, some request or response shape was changing almost daily, and nobody had OpenAPI experience … it sadly didn’t become a priority.

then, in the past ~5 or so weeks, having an OpenAPI spec that both the mocks and the actual server responses were validated against would have prevented several problems, and would have boosted productivity.

Thankfully, Philip “pfrilling” Frilling had already gotten significant parts working (and he was able to reuse Lee’s work on the Decoupled Layout Builder API module!). It was not yet mergeable because it didn’t validate the actual server responses yet.
So I started pushing it forward and ran into PHP dependency hell, was able to fix that, and then got us onto OpenAPI 3.1.0 (instead of 3.0.0), enabling XB’s openapi.yml to use patternProperties, without which we actually cannot express all of XB’s response shapes.

Hurray! A whole class of productivity blockers gone! (And Lee was right all along, of course.)

Shape matching woes

Last week’s StorablePropShape worked okay, but Ted “tedbow” Bowman’s work on #3446722: Introduce an example set of representative SDC components; transition from “component list” to “component tree” revealed an interesting edge case: JSON object keys are always strings, so 50 is encoded as '50', meaning … the type is changed, and information is lost. Fortunately, Drupal core solved this a decade ago: we (re)discovered Drupal core’s ::storageSettingsFromConfigData(), which was added for precisely this purpose! A simple fix by Utkarsh “utkarsh_33” later, and we were good to go :)

That wasn’t the only problem #3446722 surfaced: we figured out why exactly the JSON schema validation refused to accept a sample value generated by Drupal core’s uri field type … and it turns out that’s simply because that field type indeed generates invalid URIs! We worked around it by swapping the class and overriding the logic to generate valid sample values. ¹

In other words: matching the SDC props’ type information (expressed as JSON schema) against Drupal’s Typed Data/Entity/Field/Field Property type information (expressed as DataType plugins + validation constraints) is definitely revealing interesting problems that probably nobody else has been running into :D

P.S.: we set a new record by a significant margin this week: 16 MRs merged!

Week 13 was August 5–11, 2024.