Open johngtb opened 3 years ago
I considered doing that, but if I remember correctly I did not go in this direction mainly for these reasons:
Maybe that was the wrong decision and I should have looked into it more closely. If someone wants to work on a proof of concept and gets good results I am willing to reconsider.
I considered doing that, but if I remember correctly I did not go in this direction mainly for these reasons:
- making ajv required for too many use-cases bothers me, I try to limit third-party dependencies as much as possible
- ajv errors are not always very readable
- ajv errors are not internationalized
Maybe that was the wrong decision and I should have looked into it more closely. If someone wants to work on a proof of concept and gets good results I am willing to reconsider.
Hi @albanm, thanks for the quick response
I totally agree with the points you mentioned, that's why I suggest it as an optional flag to be passed besides options.ajv
.
Also, for points 2 and 3, quickly going through Ajv docs I found that one can combine ajv-i18n with the passed instance or maybe custom errors can be implemented with ajv-errors
Here's a quick example that worked for me.
However, I had to add some Vjsf keywords to the passed Ajv instance so that it won't complain
ajv.addVocabulary(['key', 'x-options', 'x-props', 'x-display', 'x-rules'])
I think turning off strict mode in ajv also does the trick.
Results as @albanm expected, not the neatest error messages from ajv and no internationalization out of the box:
But moving Ajv validation after Vjsf's rules (in the commit above) made Ajv handles only the validations that was not caught by Vjsf:
I'm still looking for a clean way to customize/internationalize Ajv's messages outside Vjsf
A solution for internationalization by passing a localization function from require('ajv-i18n')
First, thanks for the efforts put into this awesome project!
I can see that currently an instance of Ajv can be passed in options for conditional subschemas use-case, I wonder if is it possible to allow optionally using this instance to leverage Ajv validation and error messages production for form inputs? This should allows extending Vjsf to handle more formats easily such as 'email' when combined with 'ajv-formats' for instance.