-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Support for if, else, then rules #2506
Conversation
Added if then else logic to resolve schemas
Inspired by #2466 but without other unrelated fixes |
Looks good please merge |
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.
Looks good to me, only 1 minor change in the method's name
I'd say optimizations and other
You are correct abut the $ref issue, new test added. But i might be wrong. My intention is to make a minimal change-set to get this approved as quickly as possible as we are already using this on a separate project. Sorry if i sidestep you on this |
I totally get it-- #2466 inherited a lot of cruft from #1666 (for instance, that #1666 dropped My use cases anticipate complex schemas, which is why I didn't decouple optimizations from that PR. I think some form of optimization will still be necessary if this PR, and not #2466, is merged. |
Thanks for both your PRs @Juansasa and @nickgros ! I don't really have the bandwidth to compare implementations at the moment, would someone be able to carefully review both PRs and recommend the best plan of action (i.e., which one to merge, or if both PRs should be combined in some way)? Ultimately, I'd like to have a PR merged that has the most extensive if-else-then support, and probably we want to do that in the simplest way with the least changes. |
8a90e24
to
a08c563
Compare
Any updates? We are looking forward to |
any updates? Thanks 🙏 |
@epicfaace why not merge the simpler implementation then @nickgros can rebase his changes on top and deal with the corner cases? At least then there will be some movement on this needed feature. |
@@ -662,12 +662,40 @@ export function stubExistingAdditionalProperties( | |||
return schema; | |||
} | |||
|
|||
const resolveCondition = (schema, rootSchema, formdata) => { |
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.
Rename formdata to formData
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.
Add a comment describing what this function does
Good idea! I took a quick pass, I could use some help reviewing. Don't 100% understand how resolveCondition works / whether its implementation is correct |
This is fine with me. Many of the changes I made in #2466 are performance optimizations that I needed for my use case (I need to support very large/complex schemas with conditions). The changes I made may not necessarily even be the right approach to solve those problems. Since this PR is more straightforward and seems to enable this (very valuable!) feature, I think it's worth moving forward for the sake of improving this library. Optimizations can always come later. |
Any updates on merging this PR? @Juansasa @nickgros @epicfaace |
Also eagerly awaiting this feature! |
How is this coming? Anything I can help with? |
Great. Please add to the agenda!
Ashwin Ramaswami
…On Thu, Feb 10, 2022, 2:10 PM Nick Grosenbacher ***@***.***> wrote:
In #2700 <#2700>,
I added changes based on reviews on this PR, and also added the integration
tests that I wrote in #2466
<#2466>. We could
then look at reviewing/merging #2700
<#2700> in the
weekly meeting
—
Reply to this email directly, view it on GitHub
<#2506 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAM4MX3LAIGZA7VBDPT4EZDU2QESLANCNFSM5BV4KLHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Sorry guys missed the notifications. |
resolvedSchemaLessConditional, | ||
retrieveSchema(conditionalSchema, rootSchema, formdata) |
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.
Noticed that this was swapped (presumably to fix a bug?). Is there a test case we could add that would catch a regression?
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.
{
if: ...,
then: {minLength: 5},
minLength: 10
}
Expected behavior: inner property (minLength: 5
) should override outer property (minLength: 10
). We should add a test case for this
required: ["animal", "food"], | ||
}); | ||
}); | ||
it.only("should resolve $ref", () => { |
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.
remove .only
Added if then else logic to resolve schemas
Reasons for making this change
If else, then support is crucial for doing dynamic form while avoiding lots of complicated logics. Forms will be much easier to generate as well.
Checklist