Enum vales do not have (translatable) labels.
We need human-readable equivalents, and those equivalents must be translatable (using Drupal's interface translation mechanism).
⚠️ This should not be XB-specific.
⚠️ Out-of-scope here: translatability. Nothing in XB is translatable yet today. This will add the necessary infrastructure to make it feasible later 👍
\Drupal\experience_builder\ComponentMetadataRequirementsChecker:
- INFRA: Update
\Drupal\Core\Theme\Component\ComponentMetadata::parseSchemaInfo()to trigger a deprecation error when anenumis encountered without a correspondingmeta:enum- INFRA: Update
\Drupal\Core\Theme\Component\ComponentMetadata::parseSchemaInfo()to trigger a\LogicExceptionwhen ameta:enumis encountered whose keys do not match (i.e. are a subset or superset) the values listed in the correspondingenum.
… but rather than deprecating or a logic exception, it will simply become a hard requirement for XB.
JavaScriptComponent config entities), which use the same metadata structure as SDCs.\Drupal\Tests\experience_builder\Functional\XbConfigEntityHttpApiTest::testJavaScriptComponent() to also create a enum prop. This should first fail validation (422 response), then upon adding the matching meta:enum, it should pass validation.
This is XB's equivalent for
- TEST: kernel test asserting that a
meta:enumnot matching theenumtriggers a\LogicException
\Drupal\experience_builder\JsonSchemaInterpreter\SdcPropJsonSchemaType::toDataTypeShapeRequirements() to do the equivalent of
- INFRA: add a
getEnumOptions(string $prop): array<string, TranslatableMarkup>method to\Drupal\Core\Theme\Component\ComponentMetadatainspired byui_patterns'\Drupal\ui_patterns\EnumTrait::getEnumOptions(). (The thing thatui_patternsdoes not yet do is pass it through Drupal'st().)
That means changing e.g.
SdcPropJsonSchemaType::STRING => match (TRUE) {
array_key_exists('enum', $schema) => new DataTypeShapeRequirement('Choice', [
'choices' => $schema['enum'],
], NULL),
to actually use the meta:enum values.
(Note that here, they must NOT be translated — translation must happen at runtime — this corresponds to a FieldConfig config entity aka configuration.)
ui/tests/e2e/prop-types.cy.js to prove that the labels for the enum indeed appear in the UI, by updating the it('Enum (select) - string', () => { test case.
This is XB's equivalent for
- TEST: kernel test asserting that 2 identical
type: string, enum: […]props can have different translations for the same enum values. For example: a''enum value results inSame windowfor thetargetprop and inNonefor arelprop.
→ verifies it works end-to-end, and supports translation contexts
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/structure/component/status, with an explanation of why.enum and a matching meta:enum will now see those labels in the component inputs form on the right-hand side.
Config schema changes necessary for XB's JavaScriptComponent config entities attached to help get this going 👍
Fixing markup.
And crediting @pdureau, for our collaboration at DrupalCon Atlanta to ensure XB and UI Patterns 2 are aligned 😊