-
Notifications
You must be signed in to change notification settings - Fork 371
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
Fix conditionally required property not applying #2228
base: master
Are you sure you want to change the base?
Fix conditionally required property not applying #2228
Conversation
Fix the isRequired function's required check when having conditional subschemas - whether it is a single if-the-else or multiple if-then-else inside allOf combinator.
Make the if condition work with pattern and fix the check to work with nested properties
…equired Fix conditional required not applying
✅ Deploy Preview for jsonforms-examples ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Kaloyan Manolov seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
Thank you very much for the contribution ❤️. We will soon take a look. |
8bd14c2
to
e9946ef
Compare
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.
Thanks for this interesting contribution!!
Technically speaking, what this PR is missing is a set of unit tests, testing the new functionality in detail.
Conceptionally this is breaking new grounds for JSON Forms as this introduces dynamic evaluation mechanism which we do not do yet. This is potentially expensive and will be executed with every render call. I'm wondering whether we should
- make this behavior optional (default: false), and/or
- introduce a generic prop-adaption mechanism. Then this "advanced"
required
analysis could be manually configured by the user if they need it.- Of course then we could already provide this adapter for them.
Once we introduce this, there will be a lot of follow up requests. For example it's a bit arbitrary that we only do this for required
and not for other attributes too, e.g. title
. So I'm leaning a bit to the generic prop-adaption mechanism which would allow for arbitrary behavior while keeping JSON Forms itself slim.
What do you think?
packages/core/src/util/renderer.ts
Outdated
if (has(propertyCondition, 'const')) { | ||
return ( | ||
has(data, property) && data[property] === get(propertyCondition, 'const') | ||
); | ||
} else if (has(propertyCondition, 'enum')) { | ||
return ( | ||
has(data, property) && | ||
(get(propertyCondition, 'enum') as unknown[]).includes(data[property]) | ||
); |
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.
These will only work when values are primitives. If a value is an object these comparisons will fail. We should probably use lodash's isEqual
here to cover the more complex use cases too.
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.
You are right, there were other places as well where it was needed to compare the values with isEqual
. It is fixed in my latest commit.
packages/core/src/util/renderer.ts
Outdated
const ifInThen = has(get(schema, 'then'), 'if'); | ||
const ifInElse = has(get(schema, 'else'), 'if'); | ||
const allOfInThen = has(get(schema, 'then'), 'allOf'); | ||
const allOfInElse = has(get(schema, 'else'), 'allOf'); |
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.
This seems a bit too hardcoded. I would prefer if the logic could be generalized. For example anyOf
and oneOf
are not checked here.
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.
anyOf
and oneOf
are not checked, because they are not part of the conditionally required logic. We are only interested in required
in the then
and else
clauses of if
and allOf
is used as a method of having multiples if
-s in the schema.
packages/core/src/util/renderer.ts
Outdated
import { has } from 'lodash'; | ||
import { all, any } from 'lodash/fp'; |
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.
We use the modular imports of lodash, see line 83,84.
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 see, I have changed it in my latest commit.
The most appropriate place for me to add this |
…ditionally-required Add tests for conditionally required logic. Also make the whole dynamic check optional based on the `allowDynamicChecks` property of the `config` parameter of the `JsonForms` component.
Hi @gatanasov-asteasolutions, we were currently busy with the 3.2 release. We will discuss this proposal and what we think what the best way forward is within the team in the upcoming weeks and let you know. In the mean time:
|
…nto backmerge-jsonforms-base
…ms-base Backmerge jsonforms base
…-for-array-handling Additional checks for array handling
Hi @sdirix can you please review these changes again? The fork is updated to include the latest changes of the master branch and new changes were introduced in order to support conditionally required validations for array controls. I am also looking forward to your team's decision on the future of this proposal and if I can assist you in any way. |
Conceptually this feature is not a good fit for the code base as it is right now because:
What we would like to see is a generic extension mechanism for JSON Forms which allows to easily bring in additional functionality like this dynamic required use case. At the moment it's already possible to integrate a Ideally it should be introduced in a way which allows to Does this make sense to you? |
This PR fixes the long lasting problem of having conditionally required properties in the schema that do not show as required in the UI. It addresses issue #1390.