- Issue created by @effulgentsia
- πΊπΈUnited States effulgentsia
Postponing this on π Confirm Semi-coupled form elements can work with autocomplete Active
- Status changed to Active
3 months ago 11:25pm 30 March 2025 - π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
π 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.
- π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
π 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
- π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
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) - π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
π Split model values into resolved and raw Active is in!
- π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
Just π "There are no users matching '' error message appears after reloading the editor page Active remains blocking this
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
π "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.
- π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
This is postponed on waiting for core to tag 11.1.7
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
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 - π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
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 π€
- π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
Nope still failed on CI - might be because of the subdir setup on CI, pushed something else
- πΊπΈUnited States bnjmnm Ann Arbor, MI
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. - π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
Next step is approval from Ben
- π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
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 toentity:node/3
Will fix that export/import
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
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! π
- Assigned to larowlan
- Status changed to Needs work
15 days ago 1:45pm 16 June 2025 - π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
Un-RTBC'ing a ~month after #17 and #25.π
Reasons:
- 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.) - see this comment on the MR.
- This is missing test coverage for explicitly distinguishing between
format: uri
andformat: 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
- How is this going to work for a code component, which cannot use the
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
Tangentially related: π Decouple image (URI) shape matching from specific image file types/extensions Active .
- πΊπΈUnited States effulgentsia
transforms aren't applied until after the field value validates so we might need to revisit that.
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.
Should we open a separate issue to fix this, or do it as part of this issue, since this issue is the first to surface the problem?
- πΊπΈUnited States bnjmnm Ann Arbor, MI
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 - β
format: uri passes
-
bnjmnm β
committed 0a161589 on 0.x authored by
larowlan β
Issue #3499279 by larowlan, wim leers, bnjmnm, effulgentsia: Make link...
-
bnjmnm β
committed 0a161589 on 0.x authored by
larowlan β
- πΊπΈUnited States bnjmnm Ann Arbor, MI
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.