Closed ghbakhtiari closed 2 years ago
Thanks for figuring out a workaround. I've been scratching my head trying to figure out why one of my more complicated forms refused to validate sometimes.
Thanks for reporting. Would we need to create a new ajv instance each time the schema has changed, or might it be enough only to create a new ajv instance only when the schema has changed and the existing schema already has the id
key defined?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please leave a comment if this is still an issue for you. Thank you.
This issue still exists in the latest @rjsf/validator-ajv6
. I could easily solve this issue by removing the $id property from my json schema but I think it's something that should be solved somehow because I can imagine teams (including ourselves) who what to use the $id property. In my opinion generating a random $id every time the schema changes is a good idea. Any progress on this?
Description
Hi So my problem was that when the validation was activated for a given schema, and then the schema provided to the form changed, the validation stoped working (silently).
Here is a minimal working sample that you can recreate the bug with.
I spent many hours trying to figure out what is causing this and tried to put
debugger
s andconsole.log
s all over the library's code.Finally I found out that inside
validate.js
file, it only creates a new instance ofajv
if theadditionalMetaSchemas
orcustomFormats
props have changed.And so, it's using the same (previous)
ajv
instance when the schema has changed. So after that, in this line, theajv
instance is throwing an error with this message (which is caught):I see that the cause of this error is that both the schema's have the same
id
for the root object.BTW, I don't know whether or not it's supposed to work this way (break if the root id of the schema doesn't change when the schema itself has), but even so, I think we should properly get notified about the error - instead of validation stopping silently...
So, as a workaround, we can add a random string to the root object's
id
every time there's a change inside schema. Or remove the root object'sid
property altogether. But I think this can actually be fixed with some changes to the validation logics (maybe creating a newajv
instance if the schema has changed).Steps to Reproduce
reFetch
button to get a new schemaExpected behavior
I think the proper behavior is to have a working validation regardless of schema changes.