Make link widget autocomplete work (for uri and uri-reference props)

The blocker is in

#3516348: Allow 6.x version of justinrainbow/json-schema 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

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

This is blocked on #3493943: SDC+JS Component Sources: split default values into `resolved` and `source`, #3515227: "There are no users matching '' error message appears after reloading the editor page and #3516359: ComponentValidator ignores the set validator and creates a new one

Pushed some code that includes a cherry-pick (Squashed) of #3493943: SDC+JS Component Sources: split default values into `resolved` and `source` and #3515227: "There are no users matching '' error message appears after reloading the editor page that is working on the backend if the core patch from #3516359: ComponentValidator ignores the set validator and creates a new one 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)

#3493943: SDC+JS Component Sources: split default values into `resolved` and `source` is in!

Just #3515227: "There are no users matching '' error message appears after reloading the editor page remains blocking this

#3515227: "There are no users matching '' error message appears after reloading the editor page landed!

Reviewed. AFAICT this is blocked on #3516359: ComponentValidator ignores the set validator and creates a new one 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

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 #3516348: Allow 6.x version of justinrainbow/json-schema 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! 😄

Un-RTBC'ing a ~month after #17 and #25.😇

Reasons:

1. How is this going to work for a code component, which cannot use the link Twig function? That uses the \Drupal\Core\Template\TwigExtension::getLink() server-side logic, which is impossible to replicate on the client side. (Drupal.url() doesn't provide equivalent functionality.)
2. see this comment on the MR. 
3. This is missing test coverage for explicitly distinguishing between format: uri and format: uri+entity_autocomplete, i.e. something like:
   

       test_string_format_uri_drupal:
         title: 'String, format=uri+entity_autocomplete'
         type: string
         format: uri+entity_autocomplete
         examples:
           - entity:node/1
   

   in addition to the current

       test_string_format_uri:
         title: 'String, format=uri'
         type: string
         format: uri
         examples:
           - https://uri.example.com
   

   in all-props.component.yml

Tangentially related: #3530351: Decouple image+video (URI) shape matching from specific image+video file types/extensions.

Ready for review again

Big leap forward! 👏

Addresses many concerns I previously raised in #26. Still some Qs on the MR though.

I'd like @bnjmnm to review the client-side transforms changes. 🙏

Yes, I think we need to revisit this. I'm actually surprised we've managed to get this far with XB with this existing order of operations. It seems fundamentally incorrect. We're using AJV to validate, which means our validation is based on the json schema, which means the thing we need to validate is the prop value, but we don't have a prop value until we run the transforms. Prior to running the transforms, we don't have a prop value, we only have a form input value, and form input values are allowed to be anything so long as the transforms turn them into a valid prop value.

The transformed versions are getting validated, but they're still valid. After digging into the implementations, the format requirements are more relaxed than I'd assumed.

If it is validating entity:node/2

• ✅format: uri passes /^(?:[a-z][a-z0-9+\-.]*:)(?:\/?\/)?[^\s]*$/i (the colon indicates a scheme and the slash indicates a path)
• ✅format: uri-reference passes /^(?:(?:[a-z][a-z0-9+\-.]*:)?\/?\/)?(?:[^\\\s#][^\s#]*)?(?:#[^\\\s]*)?$/i (uri-reference is even more forgiving)

This could be made more robust with the use of pattern: but that alone would result in the scenario mentioned by @effulgentsia where the AJV validation does fail

Upon re-reviewing this ~10 days since my last review at #31, spotted one more bit to optimize and one more thing to clarify for our future selves. Did that.

Ready for hopefully final review by @bnjmnm :)

After debugging a bit with the ref-stored transforms I'm more glad it's in there and it might spare us some future headaches.

I think the back and front end scrutiny has been duly applied, and the changes are good ones, so this shall be merged.

FYI: This was significantly improved in the "x-allowed-schemes" MR over at #3530351-35: Decouple image+video (URI) shape matching from specific image+video file types/extensions.