One of the most frequently performed actions in Experience Builder (XB) is inserting a component. That UI was moved to the sidebar last week to make it immediately available. After dragging a component onto the canvas, the most common next action is modifying the default component inputs.
So that’s precisely what Jesse Baker, Harumi “hooroomoo” Jang, Luhur Abdi “el7cosmos” Rizal and Lauri “lauriii” Timmanee iterated on this week:
“Incredibly obvious 🙄”, I hear you think! You’re not wrong. But please remember we’re building all of this from scratch, based on incomplete designs. We’re iterating, and we’re getting somewhere! 😄
Issue #3485383, video by Luhur.
Robust component previews
While modifying a component’s inputs (in the “Settings” tab in the right sidebar you can see above), the preview updates live. This is a crucial part of the XB user experience.
However … Single Directory Components (SDC) can completely fail to render if/when the values assigned to an SDC’s props (i.e. what you typed into that “Settings” tab) are not yet valid. For example: if you managed to type “http” but not the rest of a URL, then that is not a valid URL.
It’s up to XB to not attempt to not update the preview as long as the Content Creator-entered values for a component (currently only SDCs, more later) are not yet valid.
This is the problem Ben “bnjmnm” Mullins, Ted “tedbow” Bowman, Jesse and I fixed after Travis Carden first noticed this. Ben led the development of the solution: performing client-side validation, using both HTML5 client-side validation (used by some Drupal field widgets) and JSON schema validation (which is possible for all SDC props). Once that infrastructure is present, it’s quite simple: don’t update the preview until the input is valid.
Fun fact: XB was using the uri field widget, which uses <input type="url">. That comes with automatic strict absolute URL client-side validation. We had to switch to the link field widget instead.
An obvious consequence: sometimes the preview doesn’t update as fast anymore. So far we’ve found this to not be really noticeable, for two reasons. First, the used field widgets are shaped to disallow invalid values as much as possible (for a type: string, enum: […], you’ll see radio buttons, for example, eliminating the possibility of invalid values altogether). Second, the inputs whose values are “most difficult” to be valid tends to be URLs, and either those URLs aren’t directly visible (in links), or they’re highly visible (images, videos) and it intuitively makes sense those can’t appear until the full, valid value is present anyway.
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!
Blocks, continued
Last week, initial support for Blocks landed, so this week two continuations of that initial support landed:
- Felix “f.mazeikis” Mazeikis, Dave “longwave” Long and I enabled the thorough validation that landed 4 weeks earlier for Block-sourced components, and given it was now thoroughly validated, it became possible to reliably enable support for rendering entire pages using XB’s page variant!1
Interesting tidbit: to avoid changes elsewhere in the XB codebase, we had to use PHP Fibers — available since PHP 8.1 — to achieve this. 🤓 - Dave and I added support for derived block plugins, which means that for example one “menu block” per menu is also available in XB, as you’d expect
Grab bag
- Dave, Jesse and Ted fixed a pretty silly bug: it became impossible to drag a component in between two other components! 😅
- Jesse tightened TypeScript definitions (discovered last week while working on section saving). This helps keep out development pace high.
- Also to keep the pace high: our end-to-end test suite always started with the same single article
nodewith a prepopulated XB component tree. This made sense originally, because it literally was first possible to have a server-side-stored component tree and render it, and only then was the UI built to allow a Content Creator to build such a component tree.
We’ve long since reached that point, so it was about time we added an end-to-end test that starts with an empty canvas. Thanks, Ted & Ben! - Issue #3484671 by longwave, wim leers: Add support for block derivatives — https://git.drupalcode.org/project/experience_builder/-/commit/fdbbd78d9b6e4f8de0b650fc46643fc5bbc57d6b
Week 27 was November 11–November 17, 2024.
- 1
That means it can now render the “main content”, “page title” and “messages” blocks!