-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Smart Validator #58
Smart Validator #58
Conversation
Ideally I'd like to tag all unknown properties as warnings, maybe with an option to turn them off. |
Very cool, excited to look at this. Some related thoughts I had on validation-
|
Ajv also allows you to perform custom validation, that could also be a possibility |
docs/static/js/validator.js
Outdated
}, | ||
{ | ||
keyword: "prop_oneof", | ||
validate: custom_discriminator("a"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think of converting the schema to use if/then/else instead of oneOf for animated properties? That should improve those error messages and would not need any custom logic so would work with any validator.
One thing I'm not sure of is if that would impact the doc generation tools.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be harder to maintain, also from what I've heard if/else is not always well supported by tooling, there were some issues in the lottie-docs schema that used if/else more often
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think "if" would be easier to maintain as we currently repeat the animated definition in each oneOf.
That is interesting with the tooling support though, do you recall roughly long ago that was? If/then/else was added in draft7 (2018) so maybe it just hadn't had widespread adoption yet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was like a year or two ago
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as we currently repeat the animated definition in each oneOf
Ah my bad, I thought you meant for layers
I think most of the validation is implemented, it would be great if people could test the validator and gave feedback |
Also, probably we want to extract the validator as a JS module and publish it for others to use as a library |
I surfaced #65 while testing this out locally. Any ideas why this surfaced in your validation tooling but not other validators? Looks like it is using ajv so I'm surprised at the discrepancy. I also wonder if this could be one of the previous concerns with using "if" |
Looks like this is flagging |
In the interest of getting this in quickly so we can have it for the review period, what do people think about checking this in and we can migrate it's own repo/npm later? Not sure if it makes sense to do the warnings in a follow up if there are still some rough edges that may take time to work out. |
Here's another failing sample: https://www.jsonschemavalidator.net/s/Klsfo2z4 Looks like the shape validation fails, but afaict it does match Rectangle - so not sure what's going on... |
Fixed |
Validates ok on the validator |
Added some custom validation for keyframes, for reference this is a json showing various cases: {
"fr": 60,
"ip": 0,
"op": 60,
"w": 512,
"h": 512,
"layers": [
{
"ty": 4,
"st": 0,
"ip": 0,
"op": 60,
"ks": {},
"shapes": [
{
"ty": "el",
"s": {
"a": 0,
"k": [
200,
200
]
},
"p": {
"a": 1,
"k": [
{
"_comment": "valid, has i/o",
"t": 0,
"s": [200, 200],
"i": {"x": 1, "y": 1},
"o": {"x": 0, "y": 0}
},
{
"_comment": "invalid t <= previous t",
"t": 0,
"s": [200, 200],
"i": {"x": 1, "y": 1},
"o": {"x": 0, "y": 0}
},
{
"_comment": "valid, has h = 1",
"t": 20,
"s": [200, 200],
"h": 1
},
{
"_comment": "invalid, has h = 0 but no i/o",
"t": 30,
"s": [200, 200],
"h": 0
},
{
"_comment": "invalid, needs i/o",
"t": 40,
"s": [200, 200]
},
{
"_comment": "valid, last frame",
"t": 50,
"s": [200, 200]
}
]
}
},
{
"ty": "fl",
"c": {
"a": 0,
"k": [
0,
0,
0
]
},
"o": {
"a": 0,
"k": 100
}
}
]
}
]
} |
Yeah that was my idea, keep it here until we are ready to publish 1.0 so it's easier to develop |
A couple more minor issues/feedback. Some of these are probably fine to wait for a separate PR
|
I think most of those points have been fixed. I think it would make sense to use the validator in unit tests as it can provide more granular output than simple pass/fail (it can tell which objects are failing) |
Yeah, this is looking great! |
Great to see! Let's get this in so we can start reviews, and can continue to iterate as needed. |
Currently using https://ajv.js.org/ for schema validation. Depending on how things work we might want to switch to completely custom validation to ensure the errors are sensible