Component restrictions

wim leers → credited ctrladel → .

wim leers → credited lauriii → .

wim leers → credited pdureau → .

@pdureau first made me aware of ✨ Allow SDCs to specify what components are allowed in its respective slots Active at DrupalCon yesterday.

I then discussed this with @pdureau and @lauriii. Lauri indicated he thinks this is something for much later for XB. It sounds like @larowlan disagrees?

Then later yesterday, I met with @ctrladel at DrupalCon, and he brought up this same problem space! I encouraged him to chime in on #3514072. He feels strongly that we should have the same flexibility as https://www.drupal.org/project/layout_builder_restrictions → , but with a far better UX.

@ctrladel and I high-level specced out what this would/could/should look like in XB, inspired by LB Restrictions. The patch is what we came up with: a new "slot restrictions" component config entity type to allow reusing the same slot restrictions on multiple slots. (LB Restrictions' need to define the restrictions per slot, per content entity type bundle is what makes setting it up quite onerous.)

The remaining challenge is that @lauriii has made it clear that it should be possible for an SDC that is part of a design system/a theme to specify these restrictions in code. I think that's feasible, and we have two choices:

1. define the slot restrictions in every individual SDC of the theme, hence unavoidably causing a lot of repetition, but with the benefit that it's really all still in a single directory
2. define the slot restrictions in a set of config/optional/experience_builder.slot_restriction.*yml config entities, thereby causing less repetition

If we choose option 2, then there's no extra work for XB.

If we choose option 1, then we'll also need:

• we'll need to add optional additional SDC metadata to allow defining those restrictions in code — details TBD, but IMHO that'd mean not specifying $schema: https://git.drupalcode.org/project/drupal/-/raw/HEAD/core/assets/schemas/v1/metadata.schema.json at the top of your SDC, but a superset of that one provided by XB, to add the slot restriction support
• when a theme is being installed, we could auto-generate the various "Slot Restrictions" config entities from the theme's SDC's slot restrictions defined per the above
• … but it'd require deduplicating them, and generating random identifiers
• which then brings us to the same place as choice 2, but with SDCs' original DX being retained.

Personally, I think the repetition aspect alone is sufficient to go with choice 1.

I just caught up on #3514072, and ended up being influenced by the discussion on that issue beyond what @ctrladel and I discussed yesterday! 😄

See #3514072-16: Allow SDCs to specify what components are allowed in its respective slots → and -17 for my proposal 😊

Just to reiterate from above, there's a UX implication here as well as a visual identity one.
One of the issues with LB is the overwhelming amount of component options and restrictions can yield a much leaner experience.
In terms of implementations in the FE, in decoupled LB we were sending restrictions with block metadata and using them to control dropzones - if you visit https://project.pages.drupalcode.org/decoupled_lb/?path=/story/component... and click the ➕ then try to drop the Umami disclaimer into the two col layout you see it doesn't let you.

We should be able to do something similar here hopefully

@ctrladel has been having conversations at DrupalCon about this problem space, and another aspect came up: the ability to limit the number of component instances in a slot: maybe there should be >=1, >=2, <5 — any such kind of limit. This exists for the Layout Builder ecosystem in contrib: https://www.drupal.org/project/layout_builder_limit

Kyle really impressed upon me how essential this is for building actual design systems in the real world. He's made it clear that it really needs to be part of a 1.0 release.

On top of this, @kristen pol also expressed to me the other day how when using Experience Builder with all of the components that https://www.drupal.org/project/demo_design_system → provides, the left-hand sidebar can be very overwhelming, which @larowlan just confirmed in #7.

@lauriii Given the above, can you confirm that you agree this is a stable blocker (aka 1.0 blocker)? If you disagree: why?

A patch that expands what #5 did, to make #8 more tangible.

@lauriii has clarified his POV: there are plenty of (visual) page builders out there, that are design system-aware, that do not support this functionality. He thinks it's very important, but not a stable (1.0) blocker.

If somebody in the community wants to pick this up, we'd more than welcome it, but the XB team won't be working on this before 1.0.

Here's a proposal that continues the line of thinking in #3514072-19: Define how to handle SDC component filtering in the different display builder UIs (aka. What is possible to add in a SDC slot) → (read that comment for details), but makes the following changes:

• Moves all the new keys proposed in that comment into a new file COMPONENT.traits.yml in the same directory as the SDC.
• Renames slotted to intendedFor.
• Simplifies the condition syntax by starting with the prop and within that nesting the trait values for a given prop value.

accordion_group.traits.yml

slots:
  items:
    width: full
    luminance: 80
    intendedFor: [accordion_item]

accordion_item.traits.yml

is: [accordion_item]
width: full
luminance: 20

heading.traits.yml

is: [heading, text]

props:
  color:
    light:
      luminance: 80
    dark:
      luminance: 20

See 📌 SdcController cleanup tasks Active , which acknowledged a specific piece to be out of scope, and relates closely to this issue.

#12: Thanks for cross-posting here! Note that that does not solve the reuse challenge raised in #5.

Clarifying this is a planning issue and that it is postponed for now.

(It's not hard-blocked on 📌 SdcController cleanup tasks Active , but it is conceptually connected → .)