Find bug(s) that explain unmatched field type props

String data needs the StringSemantics constraint in order to match against formats etc, so added those to password item props.

The comment_last_name field is computed, so marked that as unsupported (core bug).

Also updated the comments for path fields because the whole field item list is computed.

There's some test fails here because I didn't update the tests to include the 'Article author's password' as a source.

I'm thinking this is a red flag that we shouldn't support password fields ever.

Thoughts?

I'm thinking this is a red flag that we shouldn't support password fields ever.

+1 — I don't see why, either.

I think we should consider special-casing this field type, to ensure it doesn't get listed in \Drupal\Tests\experience_builder\Kernel\EcosystemSupport\FieldTypeSupportTest::SUPPORTED anymore, because we should explicitly not support it.

Removed support for password with an explicit test

green now

The comment_last_name field is computed, so marked that as unsupported (core bug).

What's the core bug? Is "core" referring to Drupal core, or some other meaning of "core"?

What's the core bug? Is "core" referring to Drupal core, or some other meaning of "core"?

I guess the first question is - should we be able to map dynamic prop sources in XB to computed fields in Drupal.

If the answer is yes, then I think we need a core issue to flag those comment fields as computed - but we also need an override in XB to add the string semantics (aka the format key from JSON schema) to that we can ascertain what sort of value they hold.

Can you clarify if the expectation is that you can setup dynamic prop sources against computed fields?

Yes, once we implement dynamic prop sources at all, it should be possible to "link" (the terminology that the UI will use for this) component props to computed fields as well as to computed properties of field items.

I think we need a core issue to flag those comment fields as computed

Oh, is the core bug that it's a computed field but not declared as such (isComputed() returns false)?

Yes that's correct

Ok, so that makes sense that that's a core bug, but why does that matter to XB's shape matching? What are we doing that varies by what isComputed() returns?

Now there's the answer in #13 there is no distinction now (I think).

This needs to go back to needs work as we should be able to remove a lot more of the FALSE items in this list with custom field overrides.

off-topic
@effulgentsia in #10:

Also, renaming "props" to "properties" in the issue title. The "props" short-hand is a React convention, so I think should be reserved for React and component-based technologies that were inspired by React, including SDCs. Drupal field item properties, on the other hand, were inspired by object-oriented conventions, which typically use the unabbreviated word "properties".

Fair! I'll do this going forward. 👍

But … it's far too easy to confuse "props" and "properties". So, I do think we must continue to always disambiguate: the entire XB codebase and docs refers to "field properties" as "field props" (i.e. always with the prefix "field") vs "SDC props" (for props of SDCs specifically) vs "component props" (for props of any component that uses the term "props", which includes JavaScriptComponents aka "code components").
end of off-topic

I don't see how this actually relates to 📌 Discover cases where is no 1:1 map between field, prop and widget values Active — because that is solely about widgets on the content entity form.

This issue is about shape matching SDC props with field types, and hence show field widgets for those SDC props, which means it's about widgets on the component instance form.

As discussed at #3487284-18: [META] Add explicit end-to-end test coverage for using all core field widgets including multiple cardinalities in the "Page Data" (content entity) form → , that means it belongs under 🌱 [META] Expand support to *all* SDC prop shapes, and *all* Active instead.

Actually, #18 is wrong, too! 😅

• It is about what field properties can be mapped into component instances.
• But it is not about the component instance form: field instances indeed appear in the content entity form. That means @larowlan was kinda right.
• Except … that it doesn't really matter (for 📌 Discover cases where is no 1:1 map between field, prop and widget values Active ), because on the component entity form, all field widgets must work anyway — even those whose data cannot be mapped into component instances.

So, it really doesn't belong on 🌱 [META] Expand support to *all* SDC prop shapes, and *all* Active either — if anything, it belongs on 🌱 [META] 7. Content type templates — aka "default layouts" — clarify the tree+props data model Active .

P.S.: eventually those unmatched field instances may end up being usable anyway, thanks to adapters (example: \Drupal\experience_builder\Plugin\Adapter\UnixTimestampToDateAdapter) being used in AdaptedPropSources. But the UX for that is not yet defined.

Ready now, because:

1. Not yet supported: a JSON schema (prop shape) for the following fields: test_optional__decimal, test_optional__language, test_optional__telephone, test_required__decimal, test_required__language, test_required__telephone
   

   and

   Not yet supported: a JSON schema (prop shape) for the following field properties: test_optional__decimal.value, test_optional__language.language, test_optional__language.value, test_optional__telephone.value, test_required__decimal.value, test_required__language.language, test_required__language.value, test_required__telephone.value
   

   … all of which is entirely reasonable: JSON Schema does not have native ways to express telephone numbers nor language references, and the "decimal" field type requires an adapter to be converted to a (JSON Schema) float. Instances of all other field types are either supported or explicitly ignored.

   BTW: this is now printed using E_USER_DEPRECATED, so that also fixes 📌 CI: surface the list of field types, field type props and field widgets not yet supported by XB Active . 👍

2. The explicitly ignored list is \Drupal\experience_builder\ShapeMatcher\JsonSchemaFieldInstanceMatcher::IGNORE_FIELD_TYPES and now also speeds up the matching. They are:
   

   public const IGNORE_FIELD_TYPES = [
       // The `list` field types allows each field instance to define its own set
       // of possible values. The probability of this exactly matching the explicit
       // inputs for a component is astronomical.
       // If we ever decide to allow this, then the `Choice` constraint must be
       // correctly specified on it. Otherwise, `::toDataTypeShapeRequirement()`
       // does not find any constraints and matches every such field instance
       // against every integer/float.
       'list_float' => ListFloatItem::class,
       'list_integer' => ListIntegerItem::class,
       'list_string' => ListStringItem::class,
       // The `map` field type has no widget, is broken, and is hidden in the UI.
       // @see https://www.drupal.org/node/2563843
       // @see \Drupal\Core\Field\Plugin\Field\FieldType\MapItem
       'map' => MapItem::class,
       // The `password` field type can never contain data that could be reasonably
       // displayed in a component instance.
       // @see \Drupal\Core\Field\Plugin\Field\FieldType\PasswordItem
       'password' => PasswordItem::class,
     ];
   

   … which is also entirely reasonable.

3. Finally, this now gets us to:
   

     /**
      * The current % of supported field types whose instances can be matched.
      */
     public const COMPLETION = 0.8846153846153846;
   
     /**
      * The current % of supported field type props.
      */
     public const COMPLETION_PROPS = 0.8918918918918919;
   

   … but it really is ~100% for most sites in practice: few sites use the telephone, language or decimal field types for crucial data.

IOW: as of this issue, it's clear that essentially all structured data can be exposed via DynamicPropSources and hence via ContentTemplates! 🥳

Oh and regarding #20.1 and language references: 🐛 LanguageItem lacks a schema for its default values Active blocks using it until XB requires a core version that includes it.

Automatically closed - issue fixed for 2 weeks with no activity.