[PP-1] Make link widget autocomplete work (for uri and uri-reference props)

Postponing this on 📌 Confirm Semi-coupled form elements can work with autocomplete Active

The blocker is in

📌 Allow 6.x version of justinrainbow/json-schema Active is going to be needed here because it uses filter_var to validate URLs and that means entity:node/3 doesn't validate as a valid URI.

https://github.com/jsonrainbow/json-schema/pull/800 is what fixes this upstream but it's only in the 6.x branch.

I think I have a way to work around #6 in the meantime

🐛 ComponentValidator ignores the set validator and creates a new one Active prevents us from being able to do this using the APIs provided by justinrainbow/json-schema

This is blocked on 📌 Split model values into resolved and raw Active , 🐛 "There are no users matching '' error message appears after reloading the editor page Active and 🐛 ComponentValidator ignores the set validator and creates a new one Active

Pushed some code that includes a cherry-pick (Squashed) of 📌 Split model values into resolved and raw Active and 🐛 "There are no users matching '' error message appears after reloading the editor page Active that is working on the backend if the core patch from 🐛 ComponentValidator ignores the set validator and creates a new one Active is applied

On the frontend - current status is the autocomplete value (e.g Some node title (3) doesn't validate with ajv as a uri and hence the field is invalid. I have written a transform to translate this to a uri (entity:node/1) but transforms aren't applied until after the field value validates so we might need to revisit that. Started looking at ajv keywords which are a schema extension that adds support for transforms - but these don't work on strings, only on nested data/objects (because the string is passed by value when we call jsonSchemaValidate)

📌 Split model values into resolved and raw Active is in!

Just 🐛 "There are no users matching '' error message appears after reloading the editor page Active remains blocking this

🐛 "There are no users matching '' error message appears after reloading the editor page Active landed!

Reviewed. AFAICT this is blocked on 🐛 ComponentValidator ignores the set validator and creates a new one Active shipping in a release of Drupal core ( https://www.drupal.org/project/drupal/releases/11.1.6 → does not yet contain it), and bumping XB's core requirement to that core version.

This is postponed on waiting for core to tag 11.1.7

11.1.7 was released.

No real complaints from a BE POV — self-fixed the high-level docs remarks.

I'd like @bnjmnm to review the FE + docs in detail though.

P.S.: autocomplete-props.cy.js was failing, re-tested: https://git.drupalcode.org/project/experience_builder/-/jobs/5229137

P.S.: autocomplete-props.cy.js was failing, re-tested: https://git.drupalcode.org/project/experience_builder/-/jobs/5229137

saw that happen, did some stability changes, did some repeat runs locally and it looks ok 🤞

Nope still failed on CI - might be because of the subdir setup on CI, pushed something else

How much of the current MR is due to 📌 Allow 6.x version of justinrainbow/json-schema Active not yet being in? It's mentioned in a few areas
but I'm not 100% what would be different once this is in.

The main thing I'm wondering is, once that lands, would we still need to define the format in the front end? If that's the case there should be explicit explanations of when that's necessary vs the established approach of using the schema from the BE-returned component prop definition. The BE was previously the source of schema truth and I'd like to know when/why that should be deviated from. It's possible this is info is implicit in the docs already in the MR, but I couldn't parse with certainty.

Next step is approval from Ben

cross post

The main thing I'm wondering is, once that lands, would we still need to define the format in the front end? If that's the case there should be explicit explanations of when that's necessary vs the established approach of using the schema from the BE-returned component prop definition. The BE was previously the source of schema truth and I'd like to know when/why that should be deviated from. It's possible this is info is implicit in the docs already in the MR, but I couldn't parse with certainty.

No, that won't change this. The move to v6 will allow us to drop all of the service provider shenanigans because v6 correctly sees entity:node/1 as a valid URI whilst v5 does not.

In terms of the FE, validation runs before transforms so we need a way to tell ajv that `This is a node title (3)` is valid before then transforming it to entity:node/3

Will fix that export/import

I've used the import from Ajv, much cleaner - and added some more inline comments to clarify why it is needed per #20

Thanks for the review!

The main thing I'm wondering is, once that lands, would we still need to define the format in the front end? If that's the case there should be explicit explanations of when that's necessary vs […]

💯 — yes, totally, because this is really a non-trivial work-around to something that a combination of upstream dependencies (Drupal core, and even Composer IIRC!) is forcing upon us! 🤪

Alas, @larowlan indicated in #23 that that updated upstream dependency won't change all that much for us, except for the provider 🤷‍♀️

Signaling that @bnjmnm should feel free to merge this when he considers it ready: RTBC! 😄