[PP-1] Support `{type: object, …}` prop shapes that require *multiple* field types

Provided more context about the problem space.

Related: #3468944-5: Update XB's `image` SDC to comply with best practices, and document those best practices → .

So, @effulgentsia is not convinced that embedding a heading (or other) component in another component of bubbling up the top-level props of the child component into an object prop in the parent component makes sense. Which means he's questioning 📌 Document supported component modeling approaches Active , because that's what 📌 Introduce an example set of representative SDC components; transition from "component list" to "component tree" Fixed implemented and 📌 Follow-up for #3446722: `side_by_side` + `accordion` (+ maybe `text`) components Active is the remaining part for 😅

That would probably mean new criteria for SDCs to be eligible for XB.

This deeply impacts https://www.drupal.org/project/demo_design_system → too — because depending on the outcome of that discussion, https://git.drupalcode.org/project/demo_design_system/-/tree/1.0.x/compo... may or may not need to change (if they're using the pattern that 📌 Follow-up for #3446722: `side_by_side` + `accordion` (+ maybe `text`) components Active is adding).

Wim Leers → credited effulgentsia → .

Wim Leers → credited lauriii → .

I asked @effulgentsia and @lauriii to respond to #5. They did, but unfortunately not here, but in a private chat. I captured @effulgentsia's response in #7.

Here's @lauriii's:

This is not on the critical path for the demo because this can be worked around

(By "the demo" he means 🌱 Milestone 0.1.0: Experience Builder Demo Active .)

They both think we should do a working session with @tedbow, @jessebaker, @lauriii, @effulgentsia, I and ideally @ctrlADel too.

An example of this problem in the current XB code base: the shoe_button SDC's icon prop. That surely seems like a legitimate use case?

The 3 options listed in the issue summary all seem less than ideal.

It seems better/simpler to add a dependency on https://www.drupal.org/project/field_union → and help get #3011348: Add widget support → done. Then we'd be able to, per https://git.drupalcode.org/project/field_union/blob/8.x-1.x/Readme.md#ho... :

FieldUnion::create([
  'id' => '<sdc provider>.<sdc name>.<sdc prop that is object-shaped with a single level underneath>',
  'fields' => [
    // … all the nested data
  ],
]);

which would then allow this in the SDC's Component config entity in XB:

dependencies:
  config:
    - field_union.field_union.<sdc provider>.<sdc name>.<sdc prop that is object-shaped with a single level underneath>
…
settings:
  prop_field_definitions:
    <sdc prop that is object-shaped with a single level underneath>:
      field_type: <sdc provider>.<sdc name>.<sdc prop that is object-shaped with a single level underneath>
      field_storage_settings: {}
      field_instance_settings: {}
      field_widget: '@todo #3011348'
      default_value: { … all the first example values for all the nested data … }
      expression: 'This should already be expressible using the existing PropExpression infrastructure.'

Assigning to @larowlan to get high-level feedback 🤞🙏

Correct me if I'm wrong:

I think one problem with Field Union is that it doesn't support arrays in a union. If it does, please just ignore this comment.

Taking the applicant from the example of the module, https://www.drupal.org/project/field_union →

I'm unable to have a categories instead of category field on the union, e.g. an applicant having two categories. Two categories might not make sense, but perhaps I want multiple tags.

In an ideal world you would be able to mix object and array however you want. That would enable such a powerful modeling tool.

Very good question, @johnwebdev! That would indeed prevent some use cases. Although it could be argued that you could just add a category_1, category_2, etc. (single-cardinality) fields to the FieldUnion, and make either 0, 1 or all of them required. It'd achieve the same. It'd only become truly weird/awkward for an unlimited cardinality field.

OTOH … AFAICT the fields in a FieldUnion are FieldStorageConfigs, not FieldConfigs. That'd mean you totally could specify them as multiple cardinality … which would make your argument moot

Searched the issue queue and found #3052670: Support multi-valued "field union"s → , which confirms that this would work, see https://git.drupalcode.org/project/field_union/blob/8.x-1.x/tests/src/Ke...

@larowlan, can you confirm I interpreted this correctly? 🙏

Addition to #13: 📌 Add constraint validation support Active would also be a hard blocker for XB relying on field_union — without it, we'd weaken XB's compliance with product requirement 14. Configuration Management.

Changing the issue title to eliminate depth >1 from scope.

Imagine widgets in collapsibles in collapsibles in collapsibles in collapsibles …

#15 hmm, I interpeted that as you can have an array of applicants => a field union field with muliple cardinality... but the applicant => the field union => cannot have any fields in it that are multi-valued.

But let larowlan confirm that!

Per discussion with @lauriii and @effulgentsia yesterday, @lauriii thinks this should not block stable, but should be possible to add post-1.0.