Skip to content
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

Closed
wants to merge 6 commits into from

Conversation

Juansasa
Copy link
Contributor

@Juansasa Juansasa commented Aug 6, 2021

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

  • I'm updating documentation
  • I'm adding or updating code
    • I've added and/or updated tests
    • I've updated docs if needed
  • I'm adding a new feature
    • I've updated the playground with an example use of the feature

Added if then else logic to resolve schemas
@Juansasa Juansasa mentioned this pull request Aug 6, 2021
2 tasks
@Juansasa
Copy link
Contributor Author

Juansasa commented Aug 6, 2021

Inspired by #2466 but without other unrelated fixes

@levyitay
Copy link

levyitay commented Aug 6, 2021

Looks good please merge

Copy link

@levyitay levyitay left a 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

packages/core/src/utils.js Outdated Show resolved Hide resolved
@epicfaace epicfaace self-requested a review August 11, 2021 01:37
@nickgros
Copy link
Contributor

I don't know if I would say the other changes in #2466 are "unrelated". At first glance, this implementation can't handle $refs in if/then/else, e.g. this test.

@Juansasa
Copy link
Contributor Author

Juansasa commented Aug 13, 2021

I don't know if I would say the other changes in #2466 are "unrelated". At first glance, this implementation can't handle $refs in if/then/else, e.g. this test.

I'd say optimizations and other

I don't know if I would say the other changes in #2466 are "unrelated". At first glance, this implementation can't handle $refs in if/then/else, e.g. this test.

You are correct abut the $ref issue, new test added.
What i mean with unrelated is the other refactoring/improvements to validation which i think is non-essential for resolving ifThen schemas and should belong in a separate PR.

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

@nickgros
Copy link
Contributor

What i mean with unrelated is the other refactoring/improvements to validation which i think is non-essential for resolving ifThen schemas and should belong in a separate PR.

I totally get it-- #2466 inherited a lot of cruft from #1666 (for instance, that #1666 dropped json-schema-merge-allof in favor of a custom solution, but it looks like you're using it with no problems).

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.

@epicfaace
Copy link
Member

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.

@Juansasa Juansasa force-pushed the if_then_else branch 3 times, most recently from 8a90e24 to a08c563 Compare August 18, 2021 08:21
@AlimovSV
Copy link
Contributor

Any updates? We are looking forward to if-then-else implementation will be released.

@jmsaulnier
Copy link

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.

any updates? Thanks 🙏

@heath-freenome
Copy link
Member

heath-freenome commented Nov 17, 2021

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.

@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) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename formdata to formData

Copy link
Member

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

@epicfaace
Copy link
Member

epicfaace commented Nov 18, 2021

@epicfaace why not merge the simpler implementation

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

@epicfaace
Copy link
Member

@nickgros any problems with that approach? is it possible that this PR may not be backwards compatible with #2466?

@nickgros
Copy link
Contributor

@nickgros any problems with that approach? is it possible that this PR may not be backwards compatible with #2466?

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.

@jmsaulnier
Copy link

Any updates on merging this PR? @Juansasa @nickgros @epicfaace
Thanks!

@ksbrar
Copy link

ksbrar commented Dec 22, 2021

Also eagerly awaiting this feature!

@dieseldjango
Copy link
Contributor

How is this coming? Anything I can help with?

@heath-freenome
Copy link
Member

heath-freenome commented Feb 9, 2022

@Juansasa consider joining the rjsf weekly meeting on 2/11 to discuss your PR... See #2677 for details on how to join

@nickgros
Copy link
Contributor

In #2700, I added changes based on reviews on this PR, and also added the integration tests that I wrote in #2466. We could then look at reviewing/merging #2700 in the weekly meeting

@epicfaace
Copy link
Member

epicfaace commented Feb 10, 2022 via email

@Juansasa
Copy link
Contributor Author

Sorry guys missed the notifications.
I fixed the tests and a bug based on our internal usage.
Let me know if you guys need further assistance

Comment on lines +683 to +684
resolvedSchemaLessConditional,
retrieveSchema(conditionalSchema, rootSchema, formdata)
Copy link
Contributor

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?

Copy link
Member

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", () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove .only

@epicfaace
Copy link
Member

Thanks for your help @Juansasa !!! 🎉 @nickgros will take a couple of tiny changes forward in #2700 and we will make sure you get credit when the PR is merged.

@epicfaace epicfaace closed this Feb 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants