[META] Support component types other than SDC, block, and code components

"tightly bundled to an SDC" may be the issue here.

As much as I like SDC components, they are UI / design thingies not CMS / building thingies. It is better to manipulate blocks & layout plugins, not directly SDC components, and some of them (I hope most of them) will be direct conversion from SDC components.

I have already posted this image in an other issue where I warned about the coupling risk for the project:

https://www.drupal.org/project/experience_builder/issues/3454173#comment...

Not everything in a design system is a component

Let's look a bit forward. On our way to extends the design systems coverage of Drupal, we will meet other UI "artefacts" which are renderable in HTML, but which are not UI components.

2 examples:

• grid/layout systems: Very similar to components indeed, template-based too. So today they are implemented with SDC components, but it still be a different UI beast, often defined separately in upstream documentation. The model is a bit different too, instead of slots & props we have:
  • regions: looks like slots, but they can have a dynamic number of them which is not possible (and not wished) for UI components
  • container options (gutters ? fluid?)
  • regions options, would be "props of slots" ?? with different value by slot, also context sensitive, with different value by viewport
• icons: what is defined (the iconset) is not what is renderered (the icon), the main part of the definition is the discovery handler: do I zone a bitmap? do i look for SVG in a folder? do i parse a font? the the model and the renderable are different:
  • they have no slots but they may have settings (like "props")
  • a renderable will look like that: {#type: "icon", "#iconset": "foo", "#icon": "bar" } with optional settings
  • the rendering follow a dual mechanism: direct inclusion which depends of the discovery handler: unicode point, SVG markup, IMG HTML Element... or "calls", which may leverage Twig or not

We are only at the beginning of our design system journey. Do we want to introduce a specific tight coupling for each design artefact? Or do we want to manipulate known CMS objects without caring about where they from in the design implementation?

@lauriii wrote in Slack that he also images layout plugins become available in XB. But that's not listed in the product requirements. It is sort of implied by 39. Layout Builder migration though.

@lauriii, I'm curious if you could provide more color/context than what you said in Drupal Slack (which will be nearly impossible to find later anyway)? 🙏

@pdureau I'm confused why you bring "icons" into this discussion. That seems to be a much lower level thing — a design system artifact as you described it a few weeks ago. Do you consider that "another component type"? 🤔 (@lauriii can probably help clarify this too.)

@pdureau I would imagine this issue is to remove that tight coupling so that we can have other concepts like Blocks exposed in the Experience Builder. 😊 This was documented in the product requirements with the following user story:

As a builder, I can place and render blocks and fields rendered via Twig if they are exposed to the page builder as components. Blocks and fields defined in Twig should be able to render both in the preview, and the end-user facing page. This is to enable backwards compatibility with code that already exist in contrib and custom modules.

@Wim Leers We don't have a separate product requirement for layout components. We discussed them as part of the default design system and style guide discussion. What we discussed was that by default, Experience Builder would provide a single section/grid component which can be configured into different shapes. The grid system itself including columns, gutters, container options (i.e. fluid vs fixed) is configured in the style guide. This component is mainly targeted at the builder persona, which they could use to configure into different shapes as patterns and no-code components.

Exposing Layout Plugins themselves as @Wim Leers guessed has more to do with legacy support. We could discover there are valid use cases for Layout Plugins in this new paradigm but I'm not aware of any at the moment.

The grid system itself including columns, gutters, container options (i.e. fluid vs fixed) is configured in the style guide.

I don't remember discussing this. Where is that written? 🤔

@lauriii: Which component types do you currently think to make sense?

Everyone: please add to the table I just added to the issue summary! 🙏

To be able to use field formatters in XB, we could go with either Layout Builder's block-centric approach (\Drupal\layout_builder\Plugin\Block\FieldBlock) or just use field formatters directly (which would still allow for an easy upgrade path) and should help UX/performance scalability challenges (see #3365551: Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points).

To achieve the great UX that XB aims for, including "direct manipulation" of visible pieces (see #3453690: [META] Real-time preview: supporting back-end infrastructure) without imposing additional work on the component developer (regardless of "component type", name TBD), it is necessary to be able to automatically infer which (Twig) template input connects to which component input (for SDC: "props").

For example: for sdc_test:my-cta SDC, that would mean that the visible part of its template

<a {{ attributes }} href="{{ href }}">
  {{ text }}
</a>

connects to the text prop.

That requires connecting the component's template's AST (see #3453690-10: [META] Real-time preview: supporting back-end infrastructure) to the component's inputs. For an SDC this is fairly straightforward.

This may not be possible (or relevant!) for all component types though: For e.g. a block it may not be possible to do that: the SystemMenuBlock block plugin only accepts settings for defining how/what subset of the menu to render, so none of the "component's inputs" are directly visible in the template.

While working on this + #3444424: [META] Configuration management: define needed config entity types, I stumbled upon an aspect in the product requirements that is confusing, so opened an issue to get a clarification from @lauriii, the product owner: #3455036: Clarify "components" vs "elements" vs "patterns".

If I'm reading this right, this MR introduces the concept of a "component", that can contain props and slots, but is decoupled from SDCs, and therefore can forward those props and slots to a different source plugin, such as blocks and layouts. What does this enable or make better than what you'd be able to achieve by implementing a "block" SDC or "layout" SDC that performs that forwarding? If we already have the concept of SDCs, why introduce yet another concept of a "component"?

#2 gives some examples of where props and slots might be an insufficient data model, but I'm not clear how this MR resolves that.

I guess from my perspective, what's important about SDCs isn't the SD part (though that part is nice for ergonomics) but the props and slots part.

The SDC plugin manager is not like other plugin manager in core in that it doesn't support derivatives OR fire an alter hook.
This means there is no way to dynamically declare SDC plugins/components. This is by design

Oh right, I forgot about that. I think what we should do then is either:

1. Create a contrib module separate from XB that replaces/decorates the SDC plugin manager in order to allow PHP-defined SDCs, or
2. Create a contrib module separate from XB that defines an abstract "component" concept that can be rendered by SDCs or other things, similar to this MR.

Then hopefully whichever of the above we choose can make its way into core eventually.

The pro of #1 is that modules that have already begun to standardize on SDCs, like https://www.drupal.org/project/sdc_display, can work without change with not-on-disk components.

I guess the con of #1 is then the "SD" part of the "SDC" name becomes less accurate.

I'm concerned about XB defining its own component concept, and a bunch of other modules each defining their own component concept. What I prefer about #1 is that the SDC concept is already in core and has the shape we want (except perhaps if @pdureau's comment #2 is foreshadowing that XB will need to work with components that need things that can't be cleanly represented with props and slots, but I'm not clear yet on how those specific examples will relate to XB).

I intend to review @larowlan's MR first thing on Monday :)

Note that I do not think this is in the critical path for #3454094: Milestone 0.1.0: Experience Builder Demo, but it would be awesome if we can get this in place before then for sure — we'll need it for #3455753: Milestone 0.2.0: Early preview, because without it the data model would be very much incomplete.

I had to focus on other things today. (#3452512: Add component instance edit form to contextual panel is a major step forward. #3450586-26: [META] Back-end Kanban issue tracker is now conveying again what needs to happen in the short term.)

I'll review tomorrow. Sorry for the delay.

About to meet with @larowlan — but wanted to make sure I processed everything said on this issue ahead of our meeting in a few minutes 😊

1. component variants (#3390712: Add component variants to SDC)
2. the need for schema references (#3352063: Allow schema references in Single Directory Component prop schemas)
3. component categories/tags (no issue yet AFAIK)
4. … which would power component restrictions based on those categories/tags (no issue yet AFAIK)
5. about variable # of slots (the "accordion", "image gallery", etc. use cases — no issue yet AFAIK)
6. but what else? 🤔

@larowlan in #14: we have a PoC branch (built by @tedbow: https://git.drupalcode.org/project/experience_builder/-/blob/research_sd...) that decorates the existing SDC plugin manager, to prove that XB could add support for "config-defined SDCs" (in addition to the default of "code/directory-defined SDCs")

I guess the con of #1 is then the "SD" part of the "SDC" name becomes less accurate.

— @effulgentsia in #15

I'm less concerned about this consequence: every "non-directory SDC" could be converted into an SDC, exported, if you will. That's actually a literal product requirement of Experience Builder: 63. Shared components's user story says exactly that!

@larowlan in #16: Did you already open that issue? Related issues I could find: #3390980: Make SDC extensible, #3394901: No matter what I do, I can't swap the class of the SDC plugin

@larowlan just walked me through the changes in the MR attached to this issue. He identified 5 areas, each of which can be split into their own issue/MR:

1. 👍 Removing the tight coupling between a single SDC and XB's Component config entity based on the ID (this was an intentionally simplistic choice in #3444417: "Developer-created components": mark which SDCs should be exposed in XB), to both allow >1 config per component (not sure about this, because @lauriii IIRC indicated there should only be one set of default values per component, I can see both sides) as well as allowing non-SDC "components"
2. 👍 Allowing non-SDC "components" is made possible through new infrastructure (see ComponentSourceInterface and friends, and in particular the BlockComponent component source plugin for a very interesting example). @larowlan was interested/glad to see the PoC branch I linked in #21, and we concluded that for now we'd replace the plugin.manager.sdc service in XB (so: choosing #15.1, not #15.2 as in the current MR), but we eventually would want to see that in core. But ahead of it (hopefully) being in core (which would need the support from SDC maintainer @e0ipso), it'd make sense to validate that in contrib.
   So: the concrete implementation in the current MR would change to become more akin to what's in the PoC branch, but the concepts in the MR would remain.
3. 👍 Typed PHP objects in lieu of an array-based structure returned by SdcController::layout() (see ComponentLeaf(Interface) and friends) would make the tree structure better defined, and would unblock a Just-in-Time approach of loading e.g. Layout Builder into the Experience Builder UI, which in turn enables a smooth, gradual adoption/transition from Layout Builder to Experience Builder.
4. 👍 Building on top of point 3, we'd also need to allow for multiple possible places to store component trees: they may originate from more places than just an XB field (for example: LayoutBuilderSectionComponentTreeStorage), which is how the JIT loading becomes possible (using . Besides transitioning from Layout Builder, it would also enable the use case of defining multiple component trees (one per view mode — by making ComponentFieldTreeStorage aware of the render context).
5. 👍 To allow for that, it must become optional to have a Component config entity defined for every component, because when JIT-loading the component tree from a Layout Builder field (see ComponentDefinitionRepository, those config entities would not exist. This is exactly the direction we were already going in with #3461499: Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings: that too is working towards making Component config entities optional.

We didn't delve into the concrete implementation details of any of these, but they all would represent significant steps forward towards meeting the product requirements.

I'm super excited about the changes @larowlan is proposing here. Especially because in every of the 5 areas, he's bringing in relevant pieces of his vast real-world experience with Layout Builder, wanting to avoid the scalability problems he experienced there. 🙏🙏🥳🚀

(For example, we also discussed the need for per-slot restrictions on which components would be allowed, which is possible in Layout Builder using https://www.drupal.org/project/layout_builder_restrictions, but that module has scalability issues — through no fault of its own — because the "tags" are not built in, resulting in hundreds of lines of YAML in third_party_settings 😳. That validates @lauriii's thinking to make that an inherent part — see #21.4. Related: #3459088: Every XB `Component` config entity should have a `category` property.)

@larowlan will be creating concrete issues for the 5 areas mentioned in #22 😊🥳

Clarifying issue status: conveying that @larowlan is working on next steps 😊

Finally fully caught up on everything that happened in the issue queue since June 20 noon — you opened #3456064: [PP-1] Experiment: Adapt existing layout builder storage model instead of starting fresh just as I'd left for vacation. 😄

I think the draft MR here (https://git.drupalcode.org/project/experience_builder/-/merge_requests/68 is essentially a subsequent concrete iteration of the proposal over at #3456064, @larowlan?

The issue summary needs to be expanded with at least Layout Plugins, probably also Paragraphs?

I took a stab at expanding it with:

• one new row: LayoutInterface
• one new column: Has slots or not?

More needed.

Interesting observation: the first column are all existing plugin types, but one is more special than others…

Tying this to my detailed analysis for Blocks at #3462241-8: [PP-1] Decorate the SDC plugin manager and allow components defined in code.

FYI: #3379725: Make Block config entities fully validatable landed July 22, which means supporting Blocks in XB is much more feasible now. IMHO XB should support only block plugins whose config schema is fully validatable, because only then can we be confident that a block placed in an XB component tree will work reliably (prior to that, a block plugin's block settings is quite often just … a dumping ground).

IMHO #3469609: Prepare for multiple component types: ComponentTreeStructure should contain Component config entity IDs, not SDC IDs is the inevitable first step — regardless of whether we do #3469610: Prepare for multiple component types: prefix Component config entity IDs with `sdc` or not. Together with @abhisekmazumdar, I got that to green, so … consider this officially started 🤓

After reviewing the IS and considering the comments and code provided here, I think @larowlan's approach is valid.

We could try to repurpose SDCs so they can wrap blocks or layouts, but this doesn't conceptually appear to be the right thing to do - SDCs are self contained single directory components by definition, so expanding them with features beyond is scope creep.

We could try to use blocks everywhere and wrap SDCs in blocks, but then we run into the slots issue, and would have to extend blocks so they support slots in some way.

What we are trying to do here is map props/values and slots/components into (at least) three things that are conceptually different (SDCs, blocks, layouts). This is effectively a translation layer and as such should be entirely standalone from the sources and targets of the translation; therefore I think this is the correct direction for this problem.

Also re #2 and the mention of icons, #3471494: Add an icon management API is a future proposal but eventually we could end up with icons as yet another component type alongside SDCs and blocks?

We could try to use blocks everywhere and wrap SDCs in blocks

That is the way to go in my opinion. You can have a look on UI Patterns 2 implementation:

• a block plugin: ComponentBlock
• a deriver: ComponentBlock

but then we run into the slots issue, and would have to extend blocks so they support slots in some way.

Which slots issue? Blocks doesn't have to knows about slots themselves, they just have to wrap a component which will know about slots.

Using the Render API, everything is supposed to nest nicely:

[
 '#theme' => 'block',
  'content' => [
    '#type' => 'component',
    '#component' => 'example:button',
    '#slots' => [
      'label' => [
        '#type' => 'text_format',
        '#title' => 'Body',
        '#format' => 'full_html',
        '#default_value' => '<p>The quick brown fox jumped over the lazy dog.</p>',
      ]
    ]
  ]
]

Also re #2 and the mention of icons, #3471494: Add an icon management API is a future proposal but eventually we could end up with icons as yet another component type alongside SDCs and blocks?

If the proposal is accepted, icons will be another render element which will also be nestable in slots:

[
    '#type' => 'icon',
    '#icon_pack' => 'material_symbols',
    '#icon' => 'home',
    '#settings' => [
      'size' => 64,
    ],
]

And a data structure usable in props:

[
    'type' => 'object',
    'properties' => [
      'icon' => ['type' => 'string'],
      'icon_pack' => ['type' => 'string', 'pattern' => '^[A-Za-z]+\w*$'],
      'settings' => ['type' => 'object'],
    ],
    'required' => [
      'icon',
      'icon_pack',
    ],
  ],

This proposal was already tested in projects and we already know it will fit perfectly with SDC components, and anything leveraging the Render API.

The first step towards decoupling XB from SDC just landed: #3469609: Prepare for multiple component types: ComponentTreeStructure should contain Component config entity IDs, not SDC IDs. 🥳

@pdureau in #35

Interesting! I suspect you're looking at blocks through a very particular lens here: as a mechanism for rendering. (Although you'd still have to do extra work to avoid the block.html.twig wrapping markup to appear around every SDC.) Because:

That is the way to go in my opinion.

vs

Which slots issue? Blocks doesn't have to knows about slots themselves, they just have to wrap a component which will know about slots.

is a contradiction from an Experience Builder point of view AFAICT 😅

The reason blocks not knowing about slots being a problem is because we're talking about what the right abstraction layer would be for XB to deal with all components the same way, regardless of component type/source (SDC, Block, Layout …). Since blocks don't have slots, they are unable to decorate/wrap SDCs and still provide access to critical information.

I've created #3475584 to start working on "Blocks as Components" requirement. It's based on @larowan work started in MR68 (closed). It's limited scope, focusing only on blocks for now and using the "Component Source Plugin" approach, as per #12.

Another step landed: #3469610: Prepare for multiple component types: prefix Component config entity IDs with `sdc`. Component config entity IDs are now present in the client-side data model, instead of SDC plugin IDs. Next up: #3475584: Add support for Blocks as Components.

tagging for findability

We discussed this a couple of days ago at

#3516536: XB migration meeting 31 March 2025 8:30pm to 9:30pm UTC

and at DrupalCon Altanta.

Can we explicitly add Paragraphs to the issue summary list at this point?

#41: feel free to do so :) Consider this issue summary basically a wiki! 😄

Linking the relevant issue from the table.

Add Paragraphs to list in issue summary, but with TBD placeholders as we are sorting things out.

I suppose we need a Layout Blocks item as well per @larowlan's slides but I'll check with him.

Has there been any discussion about node types as components? This could be a 100% in-core case of doing something like embedding an upcoming event on a landing page, or the little-bit-out-of-core scenario like using Rabbit Hole on content types for a form of microcontent.

@deviantintegral I haven't tested this at all but given that we support blocks as components, perhaps you just need https://www.drupal.org/project/entity_block in order to embed any entity as a component?

@deviantintegral @longwave Gave a quick try to that and _mostly_ worked after fixing the entity_block schema so its blocks settings are FullyValidatable. The UI showed up, there were some issues on storing the component but I'm pretty sure that is not a big effort to fix, and probably all effort in entity_block module itself.

#46 & #47: wow, very cool! :D

@fago started experimenting with Nuxt components at #3520666: Prototype rendering JavaScript components with Nuxt, so adding that here for discoverability :)

We also have these two awesome POCs:

1. Pinto theme objects (Drupal Slack thread)
2. Layout Builder layouts (Drupal Slack thread)

Adding some more details about the Nuxt/Vue component source plugin.

I have not started working on the component-source part yet, but what Nuxt is going to need is basically a "JavaScript component plugin with externally bundled JS". So this might be something we can develop generally and make usable with multiple JavaScript frameworks with little glue to invoke the components correctly, or shipping a base-class that easy easy to extend with the glue.

After discussing this with @lauri, I am removing the stable blocker tag.

That aligns with #3520484-76: [META] Production-ready ComponentSource plugins 👍

But to convey the ecosystem importance of this, tagging post-stable priority 😊

Haha... this definitely shouldn't be assigned to me anymore :)

I've poked and prodded Lee & Daniel (on Layout Builder) and Sascha (on Paragraphs) a bunch but they have had other priorities... [no judgment!]

Wim set to "post-stable priority" so hoping these can move forward soon :)

Lee's plan for Layout Builder in Slack:

https://drupal.slack.com/docs/T06GX3JTS/F09JNG8K317