XB week 19: flickering cliffhanger

Last week ended with 12 remaining issues. Did we make it? :D

Major loose ends

Like last week, I’m starting with the major loose ends.

Thanks to the impressive work by Dang “sea2709” Tran and the reviews and guidance from Jesse “jessebaker” Baker as well as many others, Experience Builder (XB) now has a robust solution for previewing components when hovering them in the “insert” menu. It required both server-side changes (global theme asset libraries were missing previously) and client-side changes (shadow DOM didn’t offer sufficient isolation; we needed <iframe>).
The result is so nice that I almost spat out my coffee because of a deep, unavoidable “OOOOOHHHHHHHHHHHHHHHHHHHHHHHH!!!!!” when reviewing it! :D

Once a component is placed, the preview canvas’ <iframe> must be updated: an updated HTML response is fetched and rendered. But every update to the component tree must result in an update to the preview. That means any typing the Content Creator does in the component props form results in the entire preview ¹ getting re-rendered, which easily results in flickering. Jesse devised a very clever solution, inspired by … computer games!
He introduced an IframeSwapper that keeps two <iframe>s active, but with only one visible. Once the preview has updated (i.e. the invisible <iframe> has finished loading), he swaps it with the visible <iframe> ² — eliminating all flicker:

Updating the props of a Single-Directory Component (SDC) can be done by clicking the placed component in the preview, and the “component props form” will appear on the right side. This generally works well, but there are still lots of rough edges. The roughest of edges has now been fixed by Atul, Dave “longwave” Long, Travis “traviscarden” Carden and Bálint “balintbrews” Kléri (with Ben “bnjmnm” Mullins shepherding that issue after its many twists and turns to clarity): the server side now correctly handles SDC props that are required, the client side now uses browsers’ native reportValidity functionality. The result is that premature preview updates no longer occur. ³

While placing components and inspecting the component tree you’re creating, it can be handy to quickly get an overview. Browsers have ⌘+/⌘- (Ctrl+/Ctrl-) keyboard shortcuts to zoom in/out. But for XB, you typically want to zoom in/out only the preview, not the entire UI. So thanks to Jesse and Atul “soaratul” Dubey, XB now allows zooming in/out just the preview by pressing + or -. ⁴

Another rough edge in that component props form was fixed: some field widgets are highly complex, and need to load CSS/JS to work correctly. An example is the most complex widget in Drupal core: the media library widget, which we the recently added support for. Our naïve initial approach failed whenever switching between different components that each used the media library widget: the same JS was loaded again, resulting in JS errors! Fortunately, Drupal already solved this problem: Ben added ajaxPageState support — solved!

With all of those UI improvements in, parts of XB are starting to feel solid!

Better defaults

To make it easier for future (and existing) contributors to start contributing to/playing with XB, we changed two important defaults:

1. Ben made XB depend on the Media Library module, because it offers a superior UX for (re)using images
2. Deepak “deepakkm” Mishra, Ted “tedbow” Bowman and I updated the default XB config to start with an empty XB canvas

Only one 0.1 priority left!

With only one 0.1 priority left (#3469672: The XB annotations and labels should not change size when zooming), it became possible to help land non-priority fixes, such as:

• Thanks to fazilitehreem and Utkarsh “utkarsh_33”, the “duplicate” action on component instances now works as expected, rather than resulting in an error
• Jesse and Gaurav “gauravvvv” made the canvas size dynamic based on browser viewport size, improving what we landed 4 weeks earlier
• Abhisek “abhisekmazumdar” Mazumdar, Dave and I updated the XB field type to no longer store SDC plugin IDs, but Component config entity IDs (a small but necessary first step towards supporting multiple component types — starting with Blocks)

Accelerating what’s to come after 0.1

With 0.1 essentially done, it’s important to prepare for what’s next, and set us up for success and facilitate wider contribution:

• James “q0rban” Sansbury, abhisekmazumdar and Alex “effulgentsia” Bronstein made MR reviews much easier and faster by adding Tugboat integration!
• Dave ensured that OpenAPI validation errors now result in a JSON response, which unblocks #3470321: Surface API error response in the UI — for better bug reports and faster DX — the issue title says it all!
• Together with Feliksas “f.mazeikis” Mazeikis and Dave, I documented the current component discovery + SDC criteria + `Component config entity, and described the status quo in an ADR. Because the status quo is now documented in depth, we’ll be able to make it crystal clear in #3454519: [META] Support component types other than SDC and child issues how we aim to evolve XB to supporting multiple component types, reducing the time to get to consensus on how to achieve that.

Can’t wait to see what product lead Lauri “lauriii” Timmanee prioritizes for milestone 0.2! :D (Spoiler: supporting blocks and actually saving what you see in the XB UI will definitely be in there!)

Week 19 was September 16–22, 2024.