[later phase] Support matching `{type: array, …}` prop shapes

To be clear, this is so you can have a multivalue prop? Like multiple links?

#2: yes.

(Which is what you referred to in #3454125-70: Implement temporary design system for the DrupalCon Barcelona demo → , point 3.

Gotcha 👍 thanks for the clarification

While this does need design, I think we can lay the shape matching foundations. A conversation with @catch about ✨ JSON-based data storage proposal for component-based page building Active yesterday made me realize that:

1. this is more within reach since 📌 Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings Fixed than I thought
2. having this working for at least type: array, items: integer and type: array, items: string, maxItems: 2 would actually help the discussion over at #3440578

wim leers → changed the visibility of the branch 3467870-support-generating-not to hidden.

wim leers → credited catch → .

I've made progress today on updating FieldTypePropExpression, StaticPropSource and Evaluator to support type: array.

How?

By changing StaticPropSource to not be required to contain a FieldItemInterface (i.e. a single field delta), but instead allowing a FieldItemListInterface too (i.e. multiple field deltas).

It's too unorganized right now to push; expect an update tomorrow 😊

Thanks @catch for nudging me in this direction 😄

Just pushed initial test coverage in PropSourceTest::testStaticPropSource(), to test it with multiple cardinality:

    // A simple (expression targeting a simple prop) array example (with
    // cardinality specified, rather than the default of `cardinality=1`).
    $simple_array_example = StaticPropSource::parse([
      'sourceType' => 'static:field_item:integer',
      'sourceTypeSettings' => [
        'storage' => [
          'cardinality' => 5,
        ],
      ],
      'value' => [
        20,
        06,
        1,
        88,
        92,
      ],
      'expression' => 'ℹ︎integer␟value',
    ]);

It should now fail like this:

1) Drupal\Tests\experience_builder\Kernel\PropSourceTest::testStaticPropSource
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'{"sourceType":"static:field_item:integer","value":[20,6,1,88,92],"expression":"ℹ︎integer␟value","sourceTypeSettings":{"storage":{"cardinality":5}}}'
+'{"sourceType":"static:field_item:integer","value":null,"expression":"ℹ︎integer␟value","sourceTypeSettings":{"storage":{"cardinality":5}}}'

Yay, from:

1) Drupal\Tests\experience_builder\Kernel\HookStoragePropAlterTest::testPropShapesYieldWorkingStaticPropSources
Sample value 88 generated by field type integer for type=array&items[type]=integer is invalid!
Failed asserting that two arrays are identical.
--- Expected
+++ Actual
@@ @@
-Array &0 ()
+Array &0 (
+    0 => Array &1 (
+        'property' => 'ds032jpb'
+        'pointer' => '/ds032jpb'
+        'message' => 'Integer value found, but an array is required'
+        'constraint' => 'type'
+        'context' => 1
+    )
+)

(IOW: a single integer is passed, when an array of integers is needed)

to … that test passing 🤓

More coming.

I was chasing a heisenbug for a few hours today. I then eventually found the root cause.

It happens only for a list_string field type with one of its allowed values the empty string:

        [
          'allowed_values' => [
            ['value' => '', 'label' => ''],
            ['value' => '_blank', 'label' => '_blank'],
          ],
        ]

… because somewhere '' gets cast to NULL 😅

XB's tests generate a random value to verify the static prop source works end-to-end, and due to the changes in this MR (introducing the use of FieldItemList and hence calling FieldItemList::isEmpty(), which we didn't call before), this:

now resulted in

which is obviously wrong, but count() works fine:

… this is valid configuration for the list_string field type: its config schema type field.storage_settings.list_string does not forbid this.

But the UI does forbid it:

which causes:

So probably a fixed ListStringItem::isEmpty() that is more strict than the inherited \Drupal\options\Plugin\Field\FieldType\ListItemBase::isEmpty()'s implementation:

  public function isEmpty() {
    return empty($this->value) && (string) $this->value !== '0';
  }

… would not even be accepted by Drupal core maintainers! 😬

Unfortunately, I lost hours today because of this. If there was config schema validation in place, this would've been sorted out in minutes. 😭

So: not filing a Drupal core issue, ← I can't justify that, because it's a valid use case for SDC, and we can make it work.

To make #13 discoverable.

I actually think that matching field instances should be possible too, so broadening the issue title/scope 🤓

type: array breakthrough — it’s starting to work end-to-end! 😄

Soon: 🖼️🖼️🖼️🖼️ aka image galleries!

100% of remaining test failures are due to not yet supporting finding DynamicPropSources (aka existing entity field instances) for the type: array prop shape.

That's why I widened the scope in #15 — because I first thought it'd be an order of magnitude harder than supporting StaticPropSources (which is the only thing the XB UI currently supports). But it'd be a shame to let that part "fall behind", so trying to tackle this while my head is in this space 😊

1% of remaining test failures are in the Cypress E2E tests, which makes sense: the Redux integration has only been built with single-cardinality props in mind, that's changing here.

IOW: having this in also empowers 🌱 [META] Redux sync on ALL prop types, not just ones with a single [value] property Active to design a more complete solution.

Merged in all upstream changes.

We may also need to consider this in 🐛 Some components cannot be used in XB because UI prevents SDC props being named `name` Active .

going to review

@Wim Leers the direction looks good to me!

https://nerdy.dev/carousel-adaptive-anchor-positioning-with-calc-in-a-co... would be a fantastic way to demonstrate this!