Allow adding "image" props in the code component editor

This is incomplete because it still allows type: object with arbitrary other values to be specified. IOW: more validation logic is needed.

But … this should allow the FE work to begin right now:

diff --git a/config/schema/experience_builder.schema.yml b/config/schema/experience_builder.schema.yml
index b3c76f77..8f86dd25 100644
--- a/config/schema/experience_builder.schema.yml
+++ b/config/schema/experience_builder.schema.yml
@@ -102,9 +102,20 @@ experience_builder.js_component.*:
                 - 'number'
                 - 'integer'
                 - 'boolean'
-                # @todo Consider adding `array` after https://www.drupal.org/i/3467870 is fixed.
-                # @todo Consider adding `object`, but defining _arbitrary_ object shapes is not yet supported.
+                # ⚠️ Defining _arbitrary_ object shapes is not yet supported. Currently only one such shape is
+                # supported: images, which requires `type: object` plus
+                # `$ref: json-schema-definitions://experience_builder.module/image`.
                 # @see \Drupal\experience_builder\JsonSchemaInterpreter\SdcPropJsonSchemaType::computeStorablePropShape()
+                - 'object'
+                # @todo Consider adding `array` after https://www.drupal.org/i/3467870 is fixed.
+          '$ref':
+            requiredKey: false
+            type: string
+            constraints:
+              # All choices listed here must be supported: they must have a corresponding storable prop shape.
+              # @see \Drupal\experience_builder\JsonSchemaInterpreter\SdcPropJsonSchemaType::computeStorablePropShape()
+              Choice:
+                - 'json-schema-definitions://experience_builder.module/image'
           description:
             requiredKey: false
             type: label

(#3499927: Config entity for storing code components heavily restricted what props you're allowed to use. My initial thinking: add a validation constraint that checks that the user-specified prop for the code component results in a non-NULL return value from \Drupal\experience_builder\JsonSchemaInterpreter\SdcPropJsonSchemaType::computeStorablePropShape().)

That's right: #3507928-2: [Front-end] Allow adding "textarea" props in the code component editor.

What's not yet explained in #2, is the explicit validation.

We'll need to add a new validation constraint:

diff --git a/config/schema/experience_builder.schema.yml b/config/schema/experience_builder.schema.yml
index e3352d5b..26e26d27 100644
--- a/config/schema/experience_builder.schema.yml
+++ b/config/schema/experience_builder.schema.yml
@@ -96,6 +96,8 @@ experience_builder.js_component.*:
       type: sequence
       sequence:
         type: mapping
+        constraints:
+          IsStorablePropShape: ~
         mapping:
           title:
             type: required_label

This then receives every key-value pair under props, so something like

$value = [
  'type' => 'string',
  'title' => 'Title',
  'examples' => ['Press', 'Submit now'],
];

(this is the example in \Drupal\Tests\experience_builder\Kernel\Config\JavaScriptComponentValidationTest::setUp()).

The validation constraint's validator then should do something like:

class IsStorablePropShapeConstraintValidator extends ConstraintValidator {

  /**
   * {@inheritdoc}
   */
  public function validate(mixed $value, Constraint $constraint): void {
    if (!is_array($value)) {
      // If the value is NULL, then the `NotNull` constraint validator will
      // set the appropriate validation error message.
      // @see \Drupal\Core\Validation\Plugin\Validation\Constraint\NotNullConstraintValidator
      if ($value === NULL) {
        return;
      }
      throw new UnexpectedTypeException($value, 'array');
    }

    // Verify an absolute minimum of an JSON Schema definition is present. If
    // not, do not perform further validation; it's up to the other validation
    // constraints to consider this overall value invalid.
    // @todo Ideally, we'd only validate this if and only if all key-value pairs in this mapping entry are valid. That requires conditional/sequential execution of validation constraints, which Drupal does not currently support.
    // @see https://www.drupal.org/project/drupal/issues/2820364
    if (!array_key_exists('type', $value)) {
      return;
    }

    if (PropShape::normalize($value)->getStorage() == NULL) {
      $this->context->buildViolation($constraint->message)
        // @todo look at \Drupal\Core\Validation\Plugin\Validation\Constraint\ValidKeysConstraintValidator for how to surface the key ("prop name") for which this occurred so you can include it in the error message
        …
        ->addViolation();
    }
  }

}

Needs explicit test coverage, probably just a new case in \Drupal\Tests\experience_builder\Kernel\Config\JavaScriptComponentValidationTest::providerTestEntityShapes()?

Blocks #3507928, see #3507928-3: [Front-end] Allow adding "textarea" props in the code component editor.

Once the BE MR is in, the FE work can begin, after which a screenshot (or better yet: a screencast) is expected.

Tests are present 👍 CI results look promising. MR looks great, only nits! 😄

Addressed nits, updated one failing test, waiting on CI.

Just one last suggestion on the MR, but this is good to go!

Implemented the last suggestion, addressed failing CI on ESlint and merged.

Now ready for the front-end part!

@f.mazeikis We forgot to update openapi.yml and expand \Drupal\Tests\experience_builder\Functional\XbConfigEntityHttpApiTest::testJavaScriptComponent() to test either what this MR landed, or what #3507928: [Front-end] Allow adding "textarea" props in the code component editor's back-end MR landed.

I vote explicitly testing type: object, $ref: json-schema-definitions://experience_builder.module/image in the internal HTTP API integration test.

Looks like the components.schemas.CodeComponent in openapi.yml is not very precise currently (and it can't be due to #3503377: CI: introduce a nightly-only `slow-motion cypress E2E` CI job to auto-detect response latency-sensitive tests) and thanks to that, it looks like this wouldn't fail tests.

P.S.: it's thanks to @tedbow's work on #3509026: JavaScript code components slots' examples and description should be optional that I even realized #19, so crediting him for that 😄

@balintbrews was hitting

AssertionError: assert($componentSource instanceof UrlRewriteInterface) in assert()

Analyzed it. Conclusion:

1. $default_resolved_value is computed correctly, and is set to the absolute image URL that was specified as the default
2. … but ::getClientSideInfo() doesn’t yet pass that to the client, that’s up to #3493943: SDC+JS Component Sources: split default values into `resolved` and `source` to do! 😬
3. so the client cannot send the resolved value to the server, because it simply doesn’t exist on the client
4. … which then hits the UrlPreviewPropSource fallback case in GeneratedFieldExplicitInputUxComponentSourceBase::clientModelToInput() … but that is designed to only be created when there’s a need for actual rewriting
5. I’ll work around it by implementing adding a no-op JsComponent::rewriteExampleUrl() with a @todo pointing to #3493943

Done. This is the very first code component containing an image ever rendered — forgive the ugliness of my test content 🤣

I'll let @balintbrews record a magnificent screencast instead 😇😜

P.S.: all of this is only possible thanks to the work @longwave and I did on #3501902: Adding the Image component results in a state considered invalid 🥳
P.P.S.: @longwave +1'd #25's approach — crediting him.

Both pieces are in :)