Leap ahead of #3493070 in core: SDC `enum` props should have human-readable labels: use `meta:enum`

Config schema changes necessary for XB's JavaScriptComponent config entities attached to help get this going 👍

wim leers → credited pdureau → .

Fixing markup.

And crediting @pdureau, for our collaboration at DrupalCon Atlanta to ensure XB and UI Patterns 2 are aligned 😊

Exciting to see ✨ Enum vales do not have translatable labels Active be ready for review! Now let's get this going 😁 (Because XB can't wait for core to ship this in a release.)

This works and has good test coverage.

• We need a follow-up for when the core issue lands.
• We might want a follow-up to change the Code Components UI for having 2 fields and store option lists as "value => Human-friendly label" instead of having only the value as of now.

Re-reading IS I think Wim expected to implement the Code Components here too? 🤔🤔

+1 for the follow-ups mentioned in #12 📌 Leap ahead of #3493070 in core: SDC `enum` props should have human-readable labels: use `meta:enum` Active .

It took me a while to figure out why we need any change at all for JS Component.
So documenting it step by step.

Right now, the site builder will generate their prop, and select "List: string".
They see a single textfield, named "Value", with placeholder "Enter a text value", where they input their values one by one, and select the default one.

That generates:

js_component.enumcodecomponent.yml
[...]
props:
  color:
    title: Color
    type: string
    examples:
      - green
    enum:
      - blue
      - green
      - red
      - Orange
      - 'Another weird color'

One we enable the component, that transforms to:

experience_builder.component.js.enumcodecomponent.yml
[...]
        allowed_values:
          -
            value: blue
            label: blue
          -
            value: green
            label: green
          -
            value: red
            label: red
          -
            value: Orange
            label: Orange
          -
            value: 'Another weird color'
            label: 'Another weird color'

So if they input a friendly label, that's what they get. For translation, we need to translate that config entity.
There's no way we can do this right without having some value - label pair on the client, or document how their values will be generated (potentially like prop names already are). In that case we might indicate in the UI that we expect labels, not values, and ideally print the value so they can copypaste that into the code editor.

If we do that in the client, they will post the pairs (or the value can be easily calculated from the label, as prop names do). For simplicity, we use the same format than SDC (see props in js_component above).

And when we have that, it's the client who would send the enum and the meta:enum (optionally we might want a x-translation-context, or generate one server side, but that's definitely for another follow-up), and we will have the same info than a "meta:enum" complete component (or an easy way to generate it server-side), which will generate the right config entity allowed_values pairs for e.g. translation.

I think this is ready if we split the code components part, which I moved to 📌 JsComponents `enum` props should have human-readable labels: use `meta:enum` Active

We'll work on JsComponents here.

I wanted to add a new code component with 2 props, one with enums and another one with enums and meta:enums to have a yml file with this as an example.

We had tested it in XbConfigEntityHttpApiTest but I think having a code component in a yml is useful for testing and for new adopters to see how is done.

I've also fixed issues with HEAD.

Steps to test, in Summary, is also updated.

It needs to fix a complex conflict.

Partial review, but I'm pretty sure I spotted some significant simplification potential? 😇