[META] Production-ready ComponentSource plugins

Discussed #explicit-input-schema-change-strategies in detail with @longwave just now. Here are the meeting notes:

1. @longwave came up with a really really interesting proposal in #3501708-9: [SPIKE] Prove that it's possible to apply block settings update paths to stored XB component trees → for allowing us to reuse all of the existing block update path logic, seemingly without the need for additional logic/burden on block plugin maintainers!
   However … it can't actually work because we won't know which of those post-update hooks are associated with which block plugins! In theory, we could run all those block-targeting post-update hooks, but then we'd need to track for every single block-sourced component instance which update hooks have already been executed (equivalent to how core does the system-wide UpdateRegistry). That doesn't scale, just like it doesn't scale to update potentially millions of (revision) rows.
2. We agreed that different update strategies (perhaps the 3 in ExplicitInputSchemaChangeStrategyEnum in the current IS) will be necessary. And there may be a need for even more. It really depends on how a particular component source functions. Future ones: layout types, paragraph types, web components, external API shenanigans, etc. — it's literally anything. So we cannot lock ourselves into one corner.
3. … but short-term, the primary challenge is block plugins. (Worst case: we disable the SDCs and code components which add new required properties and let 🌱 [META] Robust component instance error handling Active handle it for us until that SDC/code component is edited and gets the missing props.)
4. The "track different explicit input schema versions" part described in the sibling meta → needs massive rethinking because "provider version" is meaningless in a world of post-update hooks (which is the block plugin reality today!)

Conclusion: both my ideas (articulated in this issue + #3520449) and @longwave's (at #3501708-9) have been invalidated 😅 But we both agree that 📌 Calculate field and component dependencies on save and store them in an easy to retrieve format Active is an important step towards more clarity on how we might solve this.

Opened 🐛 Block plugins need to be able to update their settings in multiple different storage implementations Active in relation to #22.

I think we're missing 📌 [PP-1] Implement client-side validation of block settings Active in the scope here - at present we're relying on the 'jsonSchema' of SDC (and via the ephemeral SDC plugin in Code components) to show validation errors in the UI but we don't have another source component that has clientside validation so can't be sure the API is ready

📌 Expand `::getClientSideInfo()` test to all ComponentSource plugins Active and 🐛 Auto-saved Javascript Components CSS changes do not work with CSS aggregation Active landed 🚢

Replacing #3497990 with 📌 Handle components without HTML wrappers Active per @lauriii at #3497990-18: [later phase] Support Block's PreviewAwarePluginInterface (and similar for other component sources) → .

Added 🐛 Components sourced from JsComponent are missing source component cacheable metadata Active .

📌 BlockComponent::checkRequirements() should disallow any block plugins whose definition declares it requires certain contexts Active and 📌 Allow component source plugins that don't have a plugin_id setting Active landed.

Added:

1. 📌 [PP-1] Refactor GeneratedFieldExplicitInputUxComponentSourceBase and FieldForComponentSuggester to need only SDC's ComponentMetadata, not SDC plugin instances Postponed
2. 🐛 Previews of SDCs with default image props broken Active

Added 🐛 JS component slots don't appear in the preview canvas until published Active .

🐛 Previews of SDCs with default image props broken Active landed a while ago. 📌 ComponentMetadataRequirementsChecker::check() should validate that the example(s) actually match the JSON schema Active landed just now.

📌 Make menu blocks (block.settings.system_menu_block:*) fully validatable Active landed in core.

🐛 JS component slots don't appear in the preview canvas until published Active was fixed in 🐛 Hovered preview for JS components in library not working Active

Added 📌 Only run XbTwigExtension inside XBPreviewRenderer Active and 🐛 After deleting all the components from the canvas, "Add section" button should be visible on the canvas Active .

Added 📌 ComponentSourceInterface::submitConfigurationForm and validateConfigurationForm are never called Active

Added 📌 Decouple generated source plugins from SDC plugins Active , 📌 [PP-1] Implement client-side validation of block settings Active , 📌 ComponentSourceInterface::submitConfigurationForm and validateConfigurationForm are never called Active .

Added 📌 ComponentMetadataRequirementsChecker::check() should validate no prop is of type object Active

🐛 Global AssetLibrary should render with its auto-saved state (if any) when rendered in the XB UI Active and 📌 Test coverage to prove that BlockPluginInterface cacheability + BigPipe support work when rendered via XB Active landed.

New category in the issue summary: . Prompted by the addition of 🐛 Image upload breaks after optional image without an image gets published Active .

Also marked ✨ Consider adding "in_preview" var to components Active as less urgent.

#3523496 was in there twice 🙈

👉️🔄

Moved 🐛 SDC prop of `type: string` with empty string listed in its `enum` results in broken input UX Active to "discovery" thanks to superb feedback from somebody in the community I've not seen before — wonderful way to start the day :)

Also: 📌 Ensure XB works with CSS + JS aggregation, including for (auto-saved) code components Active landed!

Landed:

1. 🐛 Cannot delete JS components due to component depending on them Active
2. 🐛 Components sourced from JsComponent are missing source component cacheable metadata Active
3. 📌 Only run XbTwigExtension inside XBPreviewRenderer Active
4. 📌 Handle update and delete of Block component config entities Active

Added: 📌 Include compiled CSS from global asset library when displaying component library preview thumbnails Active .

Updated the issue summary to more clearly distinguish between:

1. beta blockers (i.e. necessary for 🌱 Milestone 1.0.0-beta1: Start creating non-throwaway sites Active )
2. stable blockers (i.e. necessary for 🌱 Milestone 1.0.0: Production Sites Postponed )

📌 Include compiled CSS from global asset library when displaying component library preview thumbnails Active landed.

Removed 📌 [later phase] Support props defaults that have config dependencies Postponed , because that belongs in 🌱 [META] Production-ready data storage Active , where it is already being tracked.

Moved 📌 Handle components without HTML wrappers Active and 🐛 After deleting all the components from the canvas, "Add section" button should be visible on the canvas Active to stable blocker (but in order to understand whether that's appropriate, I actually … kinda ended up completely fixing that last one 😅)

Triaged the list of issues tagged → . Added the following missing stable blockers:

1. 📌 ComponentSourceInterface::inputToClientModel needs to support passing an entity Active
2. 💬 SDC prop "description" is not used as the form element description? Active
3. 🐛 [Needs design] Previews of pages containing (dynamically) empty blocks are malformed Active

And also one overlooked beta blocker: Assigned to: wim leers 📌 Leap ahead of #3493070 in core: SDC `enum` props should have human-readable labels: use `meta:enum` Active

Now that triaging is done, I realized/discovered that only 3 known beta blockers remain:

• sdc,js: Assigned to: wim leers 📌 Leap ahead of #3493070 in core: SDC `enum` props should have human-readable labels: use `meta:enum` Active
• sdcAssigned to: partyka 📌 ComponentMetadataRequirementsChecker::check() should validate no prop is of type object Active
• sdc,js: 🐛 SDC prop of `type: string` with empty string listed in its `enum` results in broken input UX Active
• — AFAICT fixed by a larger infra issue, being confirmed.)

Added 📌 Consider renaming the 'inputs' column on ComponentTreeItem to 'input' Active as a stable blocker.

📌 Handle update and delete of SingleDirectoryComponent `Component`s, plus missing config dependencies Active was confirmed as a duplicate 👍

Fix HTML.

Some crucial text was lost in the #47 reshuffle.

📌 ComponentMetadataRequirementsChecker::check() should validate no prop is of type object Active is in.

Added 🐛 DX & authoring experience: for SDC+code components, the example is treated as the default, may not be desirable Active to a new section.

Added these stable blockers:

• block: 📌 `BlockComponent::validateComponentInput()` allows garbage to pile up Active
• sdc,js: 📌 Test coverage to prove `GeneratedFieldExplicitInputUxComponentSourceBase::validateComponentInput()` disallows garbage values Active

Added 🐛 JavascriptComponentStorage::createOrUpdateComponentEntity should not create component entities during config sync Active

Added 🐛 Auto-saving of blocks needs to handle string-to-bool fixing Active .

Added 🐛 Preview is not accurate for the site branding block Active .

🐛 SDC prop of `type: string` with empty string listed in its `enum` results in broken input UX Active is in!

Added 🐛 Disabled SDC components are re-enabled after cache rebuild Active as a new beta blocker.

🐛 Disabled SDC components are re-enabled after cache rebuild Active landed.

Down to one remaining beta blocker again: 📌 Leap ahead of #3493070 in core: SDC `enum` props should have human-readable labels: use `meta:enum` Active .

Added @phenaproxima's 📌 Consider renaming ComponentSource plugins to ComponentType Active .

The beta parts are 99% done 🥳 — the only remaining one is 📌 Leap ahead of #3493070 in core: SDC `enum` props should have human-readable labels: use `meta:enum` Active , which is in the final stages, and the "land upstream support for this" part is already complete: ✨ Enum vales do not have translatable labels Active . 😊

h3 → h2

Moved 🐛 Handle adding page title to content Active here from 🌱 [META] Production-ready client-side data model + internal HTTP API Active .

New stable blocker: 🐛 block__content div is omitted from preview when "Use Experience Builder for page templates in this theme." is enabled Active .

wim leers → credited bnjmnm → .

Given #3526644-9: Add xb transform to webform block storage so that it works with Experience Builder → , I think we actually need something like the all-props SDC but for block plugins.

I suspect we actually need to expand what \Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent::checkRequirements() does, because block forms can use arbitrary render arrays, and those are definitely not guaranteed to just work in XB.

So I think BlockComponent::checkRequirements() would at minimum need to be expanded with calling ::blockForm() and traversing it to see if only "known to be working" #types are present 😅

Crediting @bnjmnm for putting #3526644 on my radar!

Together with @bnjmnm I articulated a proposal at #3500795-8: [PP-2] Implement client-side validation of block settings → 😊

Added 🐛 Follow-up for #3500386 Active as a stable blocker.