[11.2.0-and-up] Add support for SDC variants

Marked 📌 Add support for SDC variants Active as a duplicate.

This can be worked on now.

🥳

Removing the prefix, because that's already the reality of XB anyway :)

This is half-baked, but got good progress with it.

There might be some client changes needed. On the component config, this is its own variant_field_definition outside of prop_field_definitions.

On the client model I'm not sure if this can be like a regular prop, but that would be my first attempt.

On the component config, this is its own variant_field_definition outside of prop_field_definitions.

😱 I did NOT expect this!

What's the value/purpose of bringing this all Component config entities? For "regular" props, allowing to customize which field type, widget etc is used makes sense. But how does it make sense for selecting the component variant?

I expect this to get a *custom* treatment in the XB UI, with at minimum a custom "select variant" UI affordance, i.e. not OptionsSelectWidget, but something in React/Radix.

For storing the variant, we IMHO have 2 choices:

1. Treat "SDC variant" as an SDC-specific concept (although AFAIK code components are intended to get this too — meaning 2 distinct ComponentSources would already need to support it), and then indeed use the list_string field type as this MR currently does.
2. ⚠️ But, AFAIK @lauriii has talked about making "component variants" a top-level concept. If so, I'd expect this to be promoted to a top-level concept in \Drupal\experience_builder\Plugin\Field\FieldType\ComponentTreeItem::propertyDefinitions(), i.e. next to component_id and component_version, we'd get component_variant. I'd expect that to be NULL when a component doesn't use variants, and for it to be a string when it does.

   (Which would then make it queryable too.)

   Last time we added a field property/column (to prove adding new properties to the component tree is viable): ✨ [PP-2] Allow users to name components for the specific context Postponed . I think this could follow exactly that pattern.

Summoning @lauriii to provide clarity on this. Because this product decision really determines the technical implementation.

Also, IMHO this should update tests/modules/xb_test_sdc/components/simple/heading/heading.component.yml to remove the element prop and move those enum choices to variant 😇

I think variants is a broader concept than just SDCs. For example, display modes for a block are conceptually very similar and could be considered a variant of the block. I do think bringing it to top level would make sense because as a top level concept, we would probably want to allow tracking usage of variants in future.

I'm moving this to a stable target since if we don't get to this, we could document that XB doesn't have support for variants (yet).

Great, that means @lauriii confirms #8.2 👍

Thanks!

See docs/adr/0006-One-field-row-per-component-instance.md which covers this too in the same way it's mentioned in #8.2