Discover cases where is no 1:1 map between field, prop and widget values

I opened ✨ [PP-1] Make link widget autocomplete work (for uri and uri-reference props) Postponed as a child issue.

AFAICT 📌 Move clientside assumptions about prop form data shape into a series of prop specific transforms Active fixed this. Can you confirm? 🙏

I think there are a few more curly bits here:

• Element validate callbacks - e.g entity autocomplete elements change the value set on a field in a validation callback - we have no way to do this yet without submitting the Drupal form structure via the form submitter - 📌 Support server side massage and validation of component prop form values Active is probably where we'd handle that
• Value callbacks - e.g. date time element takes the incoming values and converts them into something else - I think transforms have resolved this, but we need to confirm - like in 📌 Support server side massage and validation of component prop form values Active as well
• Things where the shape of what we store is different to the resolved props in the model and we can't resolve them client-side - e.g. media references - we store target_id but resolve to src/alt/width/height - 📌 Support server side massage and validation of component prop form values Active , 📌 Split model values into resolved and raw Active and 📌 Maintain a per-component set of prop expressions/sources Active will hopefully resolve that

So it would be good to keep this open in the meantime, but postponed on those.

🤩 Clearly you've got a deep handle on this problem space, and I'm very grateful for that! 😊🙏

📌 Support server side massage and validation of component prop form values Active and 📌 Maintain a per-component set of prop expressions/sources Active landed, which means this is now only blocked on 📌 Split model values into resolved and raw Active

This ties into 📌 Provide visibility into which (core) field type props can be mapped into Content Type Templates vs not Active : the \Drupal\Tests\experience_builder\Kernel\EcosystemSupport\FieldWidgetSupportTest that that introduced should be expanded here.

Since #3512433-6: Provide visibility into which (core) field types (74%), field type props (63%) can be mapped into Content Type Templates vs not, and which field widgets (36%) are supported → , FieldWidgetSupportTest can provide you with a precise list of which field widgets are not yet supported by XB (i.e. do not have the xb.transforms metadata on their plugin definition).

That makes it easier to build an overview of what the remaining work is. Especially because this issue should discover all cases, including for field types that XB does not support yet. That information is surfaced in FieldTypeSupportTest.

We want @larowlan to start tackling this this sprint, which is why 📌 Split model values into resolved and raw Active is also in the sprint.

Repurposing this as a parent meta for tracking widget support.

Adding 📌 Multiple fields widget should fully work in the contexual form Active , 📌 Get Options as buttons in Page Data form working Active as additional children

Fixing link