- Issue created by @wim leers
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
Config schema changes necessary for XB's
JavaScriptComponent
config entities attached to help get this going ๐ - ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
Fixing markup.
And crediting @pdureau, for our collaboration at DrupalCon Atlanta to ensure XB and UI Patterns 2 are aligned ๐
- First commit to issue fork.
- Merge request !898#3516602 SDC `enum` props should have human-readable labels: use `meta:enum` โ (Open) created by penyaskito
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
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.)
- ๐ช๐ธSpain penyaskito Seville ๐, Spain ๐ช๐ธ, UTC+2 ๐ช๐บ
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.
- ๐ช๐ธSpain penyaskito Seville ๐, Spain ๐ช๐ธ, UTC+2 ๐ช๐บ
Re-reading IS I think Wim expected to implement the Code Components here too? ๐ค๐ค
- ๐ซ๐ฎFinland lauriii Finland
+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 .
- ๐ช๐ธSpain penyaskito Seville ๐, Spain ๐ช๐ธ, UTC+2 ๐ช๐บ
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.
- ๐ช๐ธSpain penyaskito Seville ๐, Spain ๐ช๐ธ, UTC+2 ๐ช๐บ
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
- ๐ช๐ธSpain penyaskito Seville ๐, Spain ๐ช๐ธ, UTC+2 ๐ช๐บ
We'll work on JsComponents here.
- ๐ช๐ธSpain isholgueras
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.
- Assigned to isholgueras
- Status changed to Needs work
23 days ago 1:47pm 2 June 2025 - ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
Partial review, but I'm pretty sure I spotted some significant simplification potential? ๐
- First commit to issue fork.
- ๐ช๐ธSpain penyaskito Seville ๐, Spain ๐ช๐ธ, UTC+2 ๐ช๐บ
โจ Enum vales do not have translatable labels Active landed in time for 11.2.0
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
#28: ๐๐ฅณ
Next up: make XB leap ahead of core by landing this MR โฆ โ ๏ธ but because XB will not be able to require 11.2 until AFTER beta1, we need to be careful about how we approach it.
- First commit to issue fork.
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
Merged in upstream, let's get this to passing tests so we can land it ๐
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
@isholgueras is now (hopefully) AFK :)
- ๐ช๐ธSpain penyaskito Seville ๐, Spain ๐ช๐ธ, UTC+2 ๐ช๐บ
All tests passing ๐
Something that doesn't have e2e tests is the code editor, but we need to fix it to at least send the same values in enum as meta:enum.
Bรกlint volunteered to write this.@balintbrews For now I'd expect to send the same added values as labels. The only thing to take into account is replacing dots with underscores. Something like:
const getMetaEnumValue = (x: string) => x.replace('.', '_'); const enumValues = [ '3.14', 'b', 'c', ]; const metaEnums = Object.fromEntries(new Map(enumValues.map(value => [getMetaEnumValue(value), value]))) console.log(metaEnums); //{ // "3_14": "3.14", // "b": "b", // "c": "c" //}
- ๐ซ๐ฎFinland lauriii Finland
Any SDC that has enum without the necessary meta:enum will no longer be available to XB users, and will now appear in the list of disabled XB components at /admin/appearance/component/status, with an explanation of why.
I'm not entirely convinced that we should not allow SDCs without meta:enum to be used in XB because it is possible to achieve an acceptable UX without providing meta:enum, albeit not in all scenarios. For example, for margin-top, you could choose to provide options '4px', '6px', and '8px'. In this case the same value could apply both as the human readable and machine readable value.
We could still allow translating the enum options but keep the machine readable names consistent across translations or we could simply prevent translating these enums.
I don't think this needs to block this issue from being committed. It seems that we could loosen this requirement in future if this would require a non-trivial amount of work to change.
- First commit to issue fork.
- ๐ช๐ธSpain penyaskito Seville ๐, Spain ๐ช๐ธ, UTC+2 ๐ช๐บ
I need to self-review this yet, but feels close. Bรกlint changes look good to me, thanks!
- ๐ซ๐ทFrance pdureau Paris
I'm not entirely convinced that we should not allow SDCs without meta:enum to be used in XB because it is possible to achieve an acceptable UX without providing meta:enum, albeit not in all scenarios. For example, for margin-top, you could choose to provide options '4px', '6px', and '8px'. In this case the same value could apply both as the human readable and machine readable value.
Hi Lauriii,
According to the ๐ Don't raise exception when an enum value is missing from meta:enum Active , all SDC prop with an
enum
has also a completemeta:enum
. We made themeta:enum
optional at the YAML declaration level, but theparseSchemaInfo()
method is aligning the values:// Ensure all enum values are also in meta:enum. $enum = array_combine($prop_schema['enum'], $prop_schema['enum']); $prop_schema['meta:enum'] = array_replace($enum, $prop_schema['meta:enum'] ?? []);
Source: https://git.drupalcode.org/project/drupal/-/commit/166350f2acc649d60e4da...