Fix 4167 and 4746 in validator-ajv8

[heath-freenome]

Reasons for making this change

Fixed #4167 by adding filtering of duplicate messages related to anyOf and oneOf
Fixed #4746 by adding new extenderFn option to the CustomValidatorOptionsType used by validators and precompiled validators

• In @rjsf/validator-ajv8:
  • Updated CustomValidatorOptionsType to add new extenderFn?: (ajv: Ajv) => Ajv prop
  • Updated createAjvInstance() to add new extenderFn?: (ajv: Ajv) => Ajv parameter, using it to extend the ajv instance
  • Updated the AJV8Validator and compileSchemaValidatorsCode() to pass extenderFn from the options into createAjvInstance()
  • Updated transformRJSFValidationErrors() to add filtering of duplicate anyOf/oneOf based errors from the returned errors
• Updated validation.md to document the new extenderFn feature
• Updated CHANGELOG.md accordingly

Checklist

• I'm updating documentation
  • I've checked the rendering of the Markdown text I've added
• I'm adding or updating code
  • I've added and/or updated tests. I've run npx nx run-many --target=build --exclude=@rjsf/docs && npm run test:update to update snapshots, if needed.
  • I've updated docs if needed
  • I've updated the changelog with a description of the PR
• I'm adding a new feature
  • I've updated the playground with an example use of the feature

[TheOneTheOnlyJJ]

But does this fix #4167 for fields that are required on another oneOf/anyOf subschema, even though the Form selector is set to another subschema? Like the example with favouritePerson.

[heath-freenome]

But does this fix #4167 for fields that are required on another oneOf/anyOf subschema, even though the Form selector is set to another subschema? Like the example with favouritePerson.

@TheOneTheOnlyJJ Yes! This is from the example running on my local playground:

[TheOneTheOnlyJJ]

My mistake, I was trying to refer to fields that are required on other subschemas, but are missing completely in the currently selected subschema.

Like was mentioned here:

You can also see that favouritePerson is showing a required error message even though it is not a property of Option 1. This is because it is required in Option 3.

[heath-freenome]

My mistake, I was trying to refer to fields that are required on other subschemas, but are missing completely in the currently selected subschema.

Like was mentioned here:

You can also see that favouritePerson is showing a required error message even though it is not a property of Option 1. This is because it is required in Option 3.

Ah, right. I just wrote the filtering of duplicates. Unfortunately, doing that extra work in the validator, while possible, would require a whole lot of extra schema parsing with the formData that is currently only done while laying out the form during render. If you wanted you could customize your FieldErrorTemplate to detect whether the schema element is actually required and filter errors related to requiredness. That, in an of itself, is also a bit of a hack.

[TheOneTheOnlyJJ]

An idea that just came to me would be dynamic schema modifications done internally.

I could see something like having the subschema selector from the form trigger a function that literally cuts out all the subschemas from the oneOf/anyOf and passes that programatically reduced/normalized schema to the validator. This way, the validator does not "know" about any other subschemas but the one currently selected in the form through the selector field, and will only validate against it and no other. To take things one step further, the entire oneOf/anyOf field could probably be replaced with the currently selected subschema.

This would add the overhead of recompiling validators every time the selector is changed, unless all possible validators could be precompiled on form creation and used depending on the current subschema selection from the form. For complex schemas, this is probably unfeasible as it would take a lot of time or even memory.

This would also not work with precompiled schemas, which is a bummer.

I don't have any other ideas on how to get around this. It is a bummer that AJV itself seems to be unmaintained, as that would probably be the better place to address this. I am genuinely concerned about its future as a library.

[heath-freenome]

An idea that just came to me would be dynamic schema modifications done internally.

I could see something like having the subschema selector from the form trigger a function that literally cuts out all the subschemas from the oneOf/anyOf and passes that programatically reduced/normalized schema to the validator. This way, the validator does not "know" about any other subschemas but the one currently selected in the form through the selector field, and will only validate against it and no other. To take things one step further, the entire oneOf/anyOf field could probably be replaced with the currently selected subschema.

This would add the overhead of recompiling validators every time the selector is changed, unless all possible validators could be precompiled on form creation and used depending on the current subschema selection from the form. For complex schemas, this is probably unfeasible as it would take a lot of time or even memory.

This would also not work with precompiled schemas, which is a bummer.

I don't have any other ideas on how to get around this. It is a bummer that AJV itself seems to be unmaintained, as that would probably be the better place to address this. I am genuinely concerned about its future as a library.

Hmmmm, Food for thought. Could you write up a new feature issue with your idea? It's possible we could figure out something that could also work for precompiled schemas

[TheOneTheOnlyJJ]

Hmmmm, Food for thought. Could you write up a new feature issue with your idea? It's possible we could figure out something that could also work for precompiled schemas

I am unfortunately unable to contribute in any more meaningful way than these comments and ideas I share here and there.
I have finished my BSc and am now studying a MSc programme, which demands my entire time and energy.

I still comment and leave ideas here because I really, really like this library, and without it, my BSc thesis would have been simply unfeasible to develop. I keep up with all the updates and appreciate the effort that is being put into developing and updating it.

Side note

I finally could make my BSc thesis project repository public. If you have nothing better to do, you can check out the way I used the library here: https://github.com/TheOneTheOnlyJJ/blackbox/tree/main/src/renderer/components/forms

There is no README, and the project is quite big, so it may be of little to no value to check anything out, but virtually all of the issues I have opened here over the past year (16 issues + commented on others that affected the project) have stemmed from only this one project. I am very, very happy to see how so many of them are getting addressed. The entire project was designed around RJSF from the ground up, and with this much heavy interaction with the library, I found the many issues that I reported. I feel like it had a positive impact on the overall library.

Without RJSF, many of the project's features, which rely heavily on dynamic JSON schemas, could not have been implemented within the time constraints I had and my overall knowledge level.

And, as an end note, the academic commission was impressed with the project, and I received positive feedback on it. Again, thank you for your efforts!