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:
Hovering a section (XB calls top-level components sections) now offers placing another section and triggers the component list form.Issue #3460952, image by Harumi.
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:
The all-props test-only SDC facilitates testing/developing missing pieces of XB: it makes it easy to see the editing UX that is generated for a particular SDC prop shape.Issue #3463583, image by Wim.
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:
Notice how pink outlines appear everywhere as soon as the Hero component is previewed — that’s obviously not the intent! :DIssue #3466303, image by Jesse.
Jesse, Utkarsh and Gaurav “gauravvvv” used shadow DOM to properly encapsulate this.
Missed a prior week? See all posts tagged Experience Builder.
Goal: make it possible to follow high-level progress by reading ~5 minutes/week. I hope this empowers more people to contribute when their unique skills can best be put to use!
For more detail, join the #experience-builder Slack channel. Check out the pinned items at the top!
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. 1
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.
-
We’ll eventually create upstream issues in Drupal core, but first we’re working accumulating a range of these kinds of problems, to identify the best strategy to fix this upstream. We’re now at ten overrides for field type classes, for a variety of reasons — most for missing validation constraints and/or incorrect field property class implementations. ↩︎
Hovering a section (a top-level component) now offers placing another section and triggers the component list form.- The all-props test-only SDC facilitates testing/developing missing pieces of XB: it makes it easy to see the editing UX.
- Notice how pink outlines appear everywhere as soon as the Hero component is previewed.
