Blog

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!

The back-end heart of Experience Builder (XB) is its two-property field type. Thanks to Ted “tedbow” Bowman, the tree field property is now strictly validated, which is essential to ensure both data integrity and the ability to evolve the codebase rapidly and confidently. Crucially, this validation constraint is used to validate both content and configuration, just like the validation that was added in week 10.

This week started with undoing the horrors that y’all were subjected to last week: TwoTerribleTextAreasWidget featured prominently. The follow-up that I mentioned landed (Ben “bnjmnm” Mullins and I collaborated on it), which with a +110,-245 diff resulted in something that still is nowhere near a final UX, but is starting to look reasonable.

The Cypress front-end testing infrastructure clean-up landed on Monday, so this week we’ve already been seeing increased velocity! Last week, we landed the initial implementation of the primary menu, this week it was improved by Harumi “hooroomoo” Jang:

Experience Builder (XB) allows crafting an experience using components. A tree of components. Except that until now, the XB field type does not yet support storing a tree — we had to start somewhere! Ted “tedbow” Bowman landed #3455728: FieldType: Support storing component trees instead of lists. Next up on this front: before we start actually storing trees, we need thorough validation — Ted’s tackling that next. This will allow us to confidently store trees of components (by putting components in other components’ slots), and then finally put to good use the oldest MR the XB project currently has: Kyle “ctrlADel” Einecker’s MR that adds representative set of Single-Directory Components.

Last week was very quiet, July 1–7’s #experience-builder Drupal Slack meeting was even more tumbleweed-y…

… but while that was very quiet, the Acquia UX team’s design locomotive was getting started in the background, with two designs ready-to-be-implemented posted by Lauri “lauriii” Timmanee — he’s working with that team to get his Experience Builder (XB) product vision visualized:

1. #3458503: Improve the page hierarchy display — with Gaurav “Gauravvvv” enthusiastically jumping on it!
2. #3458863: Add initial implementation of top bar

On top of that, a set of placeholder issues was posted — choices to be made that need user research before an informed design can be crafted:

It’s Drupal Dev Days week! With Lauri presenting a Keynote there and several people out this week (myself included), it was a quiet week for Experience Builder.

Consequently, it was the first week since the 0.x branch was opened that zero merge requests landed…

Even the weekly meeting was fairly quiet.

1.5 week prior, Lee “larowlan” + Jesse fixed a bug in the undo/redo functionality and added the first unit test (#3452895), and added it to CI (where it now runs immediately, no need to wait for composer to run JS unit tests!) Except … the unit tests didn’t actually run — oops! Rectifying that revealed a whole range of new Cypress challenges, which Ben “bnjmnm” worked tirelessly to solve this during the entire 5th week, and it was merged on Wednesday of this week :)

Anybody who has contributed to the drupal.org GitLab CI templates knows how painful this can be!

We started the week off with a first MVP config entity: the component config entity. We have to start somewhere and then iterate — and iterate we can: thanks to Felix “f.mazeikis”, #3444417 landed! Most crucially this means we now have both a low-level unit test and a kernel test that ensures the validation for this config entity is thorough — of course I’m bringing config validation to Experience Builder (XB) from the very start!

My Monday started with a pleasant surprise that is only possible in cross-timezone collaborations: Ted “tedbow” ¹ had made a huge leap forward on #3450957: Prevent modules from being uninstalled if they provide field types used in an Experience Builder (XB) field, where he’s working on the first aspect where XB’s JSON blobs in the database must be queried.
Drupal 11 requires versions of databases that support JSON querying. Ted rather quickly discovered that JSON querying support is not consistent across different databases … but fortunately Brad “bradjones1 is working on #3343634 to add explicit JSON support to Drupal’s database abstraction layer, which is one of the endeavors sponsored by Pitch-Burgh! So: database nerds, unite!