Monday was a U.S. holiday, which meant I was able to go full-steam ahead on the storage MR for Experience Builder (XB) that I started the prior week. On Tuesday, I continued that work, and spun off a second MR that allows changing the source type and source value … for which I shared a 2.5-minute screencast in #experience-builder late on Tuesday.
In it, you’ll see a hacky-as-hell UI. It’s currently named TwoTerribleTextAreasWidget to convey in no uncertain terms that this is throwaway code :D Its purpose: help stand up infrastructure and get the back-end pieces in place to power the UI (see last week’s screenshot), which is currently using hardcoded data.
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!
The video is the first step in visualizing all the pieces of Alex “effulgentsia”’s data model proposal in #3440578. In a nutshell, you can see that for each placed component, this video proves:
- it is possible to exactly match Single Directory Components (SDC) props against Drupal field types (to be precise: props inside those fields)
- while allowing those values to be:
- either
dynamic: reuse of structured data that already exists on the entity (XB aims to embrace that strength of Drupal, not to diminish it) - or
static: fixed values stored in JSON-in-the-database as described in #3440578 1
- either
- crucially, we can automatically surface only sensible choices, and present the choices in an order that encourages best practices, using only schema matching2 (SDCs use JSON schema, whereas the Drupal entity/field system uses Typed Data + validation constraints)
I was relieved to see that effulgentsia indicated this indeed matches his vision :)
Just those two source types (dynamic and static) are insufficient, which is why Felix has been hard at work to bring us a working PoC of adapters too, which are able to
- adapt data into a shape that Drupal does not provide a field type for (for example: the
type: string, format: time) - combine multiple data sources (any combination of
staticanddynamic) into a single shape (for example: combine an image + Image Style inputs and to adapt them into an image that uses that style
Adapters were merged on Friday!
That was more technical than previous weeks. The more technical readers might, if they squint again just like last week for the UI, be able to see how Lauri “lauriii”, effulgentsia and I see the different pieces connect. I know that many of you are longing for detailed architectural diagrams. They do not exist today. We had to first prove what we envisioned was feasible. There’s a bit more proving to be done first, but then such documentation & diagrams will be my top priority.
Before sharing that video on Tuesday, I met with Cristina “ckrina”, Jared “jponch”, Mateu “e0ipso” and Mike “mherchel”, about design tokens, which is another crucial part of XB. e0ipso had already been working on a PoC for bringing design tokens to SDC, whereas ckrina felt it was important to start defining which design tokens should exist. We ended up concluding unanimously that building a few concrete components and making them use design tokens would help define that — so ckrina, jponch and mherchel are tackling that next.
The meeting was recorded and shared and sparked a lively discussion, where Pierre “pdureau” chimed in with interesting UI Suite-based opinions
It’s great to see this work in motion, because both the exploratory “how should it work from a design POV?” and the concrete SDC support work are necessary, and both will inform the direction of #3444424: [META] Configuration management: define needed config entity types.
On Wednesday, #3450586: [META] Early phase back-end work coordination and #3450592: [META] Early phase front-end work coordination were created, to start making it possible for any Drupal contributor to 1) see what’s happening, 2) find issues to contribute to. (The list of available issues is sparse at this early stage, because there barely is a codebase, and not all architectural puzzle pieces exist yet.)
Later that day, I rode my bicycle over to meet with 4 people of the Dropsolid team. They’re very eager to contribute to XB (their CEO, Dominique “domidc” almost didn’t let me leave the DrupalCon venue when it was closing, that’s how enthusiastic they are :D), and they bring a unique perspective: they focus on “mid-market” and have hundreds (thousand?) of sites using Layout Builder. Thanks to to that, they intimately know some of Layout Builder’s architectural choices that XB should avoid. On the code contribution side, I was able to point them to the 2 meta issues above that had been created only hours prior. On the UX/product side of XB, they’re coordinating with lauriii next, so expect to hear more in a future update.
Perhaps the best place to contribute to XB today is actually in SDC! Kyle “ctrlADel” Einecker discovered an SDC bug during DrupalCon Portland (#3446933) that definitely will block XB. e0ipso worked on a fix and penyaskito RTBC‘d it on Thursday. This also connects with #3446083 and #3446722 which focuses on defining different ways of composing components out of existing SDCs for XB to support.
Also on Wednesday, Lee “larowlan” helped the UI transition from miragejs to msw.
To round the week out, Ben “bnjmnm” finished his epic battle with the CI gods on Friday and won!: he got Cypress working on XB’s GitLab CI pipeline. Both Ben and Jesse were raving about the excellent DX that Cypress has compared to other (end-to-end) testing frameworks for JS. With the CI pieces in place, we’re ending this week on a strong note: future UI work will be able to move faster thanks to Cypress, and Cypress-on-CI!
Thanks to Lauri for reviewing this!
-
To generate field widgets for these, we conjure instances of those field types out of thin air! ↩︎
-
Schema matching basically is a fancy word for shape matching. ↩︎