[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 🙈

👉️🔄