"Developer-created components": mark which SDCs should be exposed in XB

Hi,

Are you planning to attach SDC components directly to the display config entity, without transforming them to configurable plugins (blocks, layouts, field formatters...) first?

📌 Document supported component modeling approaches Active describes several ways users would construct components in the Experience Builder context. 📌 Introduce an example set of representative SDC components; transition from "component list" to "component tree" Fixed starts implementing example components using these patterns to identify any gaps in the SDC system to express these patterns.

We had discussion about option to extend components
https://drupal.slack.com/archives/C4EDNHFGS/p1715090009402889

One thing from LB Plus/Decoupled LB that would be good to have here would be 'default layout' for a component.
So you don't need to add a layout first if you want to add a component to it. Dragging the component from a list into the page container would auto-add that layout. Dragging it into an existing layout would not.

One of the problems we need to solve is nesting of components; there are many common and valid scenarios where you need more then 2 levels of nesting. As we do this, we need to break the current assumption where blocks are always wrapped by sections, and sections always contain blocks. We can do this by introducing a single type of components. These components could be generated either by SDC, Layout plugins, or Blocks. SDC and Layout plugins have the concept of nesting where as Blocks would not have that. In this model, any component could be placed in the layout, meaning that you could place a block or SDC to the layout without adding a section first.

Clarifying title and providing context: #3444424-4: [META] Configuration management: define needed config entity types → .

Refining (narrowing!) scope. Part of what was listed as scope here was either super vague or enormous. The "new route" part is A) listed after this in 🌱 [META] Early phase back-end work coordination Active , and B) is already being worked on by @bnjmnm over at https://git.drupalcode.org/project/experience_builder/-/commit/908ce4bda... — with currently just returning all SDCs. (This issue/MR will allow us to update that code to return only opted-in SDCs.)

📌 [MR Only] provide UI foundation with Drag and Drop + panels Fixed landed, so now this issue should update Drupal\experience_builder\Controller\SdcController to respect the config entities this MR is introducing 👍

Created follow-up issue, in which I explicitly listed the scope that was removed in #11, and also provide much more detail: ✨ Allow specifying default props values when opting an SDC in for XB Fixed .

I went ahead and already assigned it to you, @Felix, because your head is currently in this space and you've built the related PoC 🤓

Pushed component entity definition + schema + ensuring dependency of SDC provider is added to Entity on creation.
Added very simple unit test to ensure config entity creation works.
Added forms, routes and menu items/actions for creating/editing/deleting entity - it's all based on existing core logic, nothing fancy, just so FE people could easily interact with new entities.
When creating component SDC selection is presented in a select dropdown, grouping SDC's by their provider.

Thanks for getting this going — first review posted :)

Explicitly associating the issue I linked in #13.

Done! This is a thoroughly tested starting point now.

Next up: 📌 Add ::calculateDependencies() to ComponentTreeItem Active , which is a small next task to unblock the much bigger ✨ Allow specifying default props values when opting an SDC in for XB Fixed .

I'll capture the comments by @lauriii, @pdureau and @finnsky in concrete issues when those areas are worked on.

Automatically closed - issue fixed for 2 weeks with no activity.