Skip to content

Mixed support #2409

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

Open
wants to merge 48 commits into
base: master
Choose a base branch
from
Open

Conversation

kchobantonov
Copy link
Contributor

@kchobantonov kchobantonov commented Dec 30, 2024

  1. provide support for mixed types
  2. fix clearing of inputs when not under an object - e.g. string once cleared will become empty string rather than to return undefined to remove the property from the parent object
  3. fix date controls, now the date can show year, year/month and etc. depending on the control option views
  4. improve the performance to convert dayjs format into maska format function
  5. fixing the :key to at least have the collection size into the key so when the size changes the vue will not reuse html elements leaving attributes like id unchanged
  6. add more examples to show how the mixed control can be used
  7. use arraySchema from the mapped values rather than using Resolve
  8. minor UI changes to use less space
  9. core changes : use the provided schema when the resolve failed, make sure that boolean is valid schema as well - e.g. items: true is valid schema (Note: the last change for the items to be boolean was reverted back since more code should be adjusted - maybe a future improvement)
  10. introduce a new config - allowAdditionalPropertiesIfMissing - this allows to show the additioanalProperties UI when the additionalProperties and patternProperties do not exist. The reason is that by default if the additionalProperties is missing from the schema the default should be considered as true but the UI component does not respect that default - e.g. it needs to be explicitly states as additionalProperties: true if the UI control is needed without the allowAdditionalPropertiesIfMissing config

…ot part of the object that has the property defined in properties then to not clear it - e.g. send undefined value
… based on index - e.g. prevent reusing elements when the array change size which will cause id properties for example to not have correct value
…n also allow such case to be handled by the object renderer
…s no need to resolve that schema just use it
Copy link

netlify bot commented Dec 30, 2024

Deploy Preview for jsonforms-examples ready!

Name Link
🔨 Latest commit 8f862d7
🔍 Latest deploy log https://app.netlify.com/sites/jsonforms-examples/deploys/681e9ae1ae7e64000841edff
😎 Deploy Preview https://deploy-preview-2409--jsonforms-examples.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@kchobantonov
Copy link
Contributor Author

@coveralls
Copy link

coveralls commented Jan 7, 2025

Coverage Status

coverage: 82.453% (-0.06%) from 82.517%
when pulling 6b863d9 on kchobantonov:mixed-support
into 0628b99 on eclipsesource:master.

@sdirix
Copy link
Member

sdirix commented Jan 10, 2025

Thanks for the contribution ❤️ I'll take a look within January 👍

Copy link
Member

@sdirix sdirix left a comment

Choose a reason for hiding this comment

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

Hi @kchobantonov,

I had a first look at the implementation. The examples work great and are really impressive ❤️

I added some comments, please have a look

Comment on lines +126 to +132
if (
typeof schema === 'boolean' &&
(!pathSegments || pathSegments.length === 0)
) {
// add the case where the schema can be true value for example: items: true or additionalProperties: false
return schema;
}
Copy link
Member

Choose a reason for hiding this comment

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

What is the use case of this? Who hands over segments to resolve if the schema is just a boolean already anyway?

Copy link
Contributor Author

@kchobantonov kchobantonov Feb 13, 2025

Choose a reason for hiding this comment

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

that is to resolve the case where the value of the last path segment is equals to true. For example items: true and you want to bind that items then you need to resolve the jsonschema which can be boolean but in the code we ignore that this can be ever the case.

Also the next check for isEmpty if we pass true/false values which are valid JSON schema will return an undefined when resolved instead of boolean

Copy link
Member

Choose a reason for hiding this comment

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

The case is already handled via

  if (!pathSegments || pathSegments.length === 0) {
    return schema;
  }

If having a boolean schema breaks the checks before that, then we should fix those checks instead of hard coding the exception at the top.

I guess the typing does not properly reflect that the schema could be a boolean. So we should adjust the typing and the checks to handle the typing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the issue was that if I was going to adjust the typing to allow true/false to be valid schema then there was a lot more changes to the code that just this one - so if the goal is go make the typing correct and the amount of changes to not be an issue then that is fine but I didn't wanted to change a lot of stuff in the core packages that was the reason to have that there

@@ -20,7 +20,7 @@
/>
<dispatch-renderer
v-for="(allOfRenderInfo, allOfIndex) in allOfRenderInfos"
:key="`${control.path}-${allOfIndex}`"
:key="`${control.path}-${allOfRenderInfos.length}-${allOfIndex}`"
Copy link
Member

Choose a reason for hiding this comment

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

Why adapt this key?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

because if the size of the allOfRendererInfo changes then the key is not stable enough to guarantee that previous keys will point the exact same elements - e.g. we do not have a primary key for the info that we can use - usually this happens when we change the UI schema and the schema have to be applied again.

Copy link
Member

Choose a reason for hiding this comment

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

Seems weird as this only fixes the case in which the uischema or schema changes and the length ALSO changes. It will not work if the length does not change.

I wonder whether there should be a change higher up, for example setting a key on the whole form and increasing it whenever we hand over a new schema or uischema. This would be a more generic fix covering all use cases, instead of only a partial fix, covering some of the use cases.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree as well but then we do need that on the core level - for now at least that is fixing the issue that I was having when I change the uischema from the monaco editor in our vue examples. So once this is available at the core - maybe some id for the uischema changes then we can utilize that.

@kchobantonov
Copy link
Contributor Author

@sdirix check my responses and also updated repo but it looks like the build failed perhaps because netlify is using greater than pnpm version 8 now ?

Copy link
Member

@sdirix sdirix left a comment

Choose a reason for hiding this comment

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

I have concerns about the proposed changes to the core functionality.

Please have a look at my new comments and the unresolved comments from my previous review.

Comment on lines +126 to +132
if (
typeof schema === 'boolean' &&
(!pathSegments || pathSegments.length === 0)
) {
// add the case where the schema can be true value for example: items: true or additionalProperties: false
return schema;
}
Copy link
Member

Choose a reason for hiding this comment

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

The case is already handled via

  if (!pathSegments || pathSegments.length === 0) {
    return schema;
  }

If having a boolean schema breaks the checks before that, then we should fix those checks instead of hard coding the exception at the top.

I guess the typing does not properly reflect that the schema could be a boolean. So we should adjust the typing and the checks to handle the typing.

@@ -20,7 +20,7 @@
/>
<dispatch-renderer
v-for="(allOfRenderInfo, allOfIndex) in allOfRenderInfos"
:key="`${control.path}-${allOfIndex}`"
:key="`${control.path}-${allOfRenderInfos.length}-${allOfIndex}`"
Copy link
Member

Choose a reason for hiding this comment

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

Seems weird as this only fixes the case in which the uischema or schema changes and the length ALSO changes. It will not work if the length does not change.

I wonder whether there should be a change higher up, for example setting a key on the whole form and increasing it whenever we hand over a new schema or uischema. This would be a more generic fix covering all use cases, instead of only a partial fix, covering some of the use cases.

@kchobantonov kchobantonov requested a review from sdirix May 8, 2025 10:04
@kchobantonov
Copy link
Contributor Author

kchobantonov commented May 8, 2025

@sdirix please review again - here are the outstanding items that I need to check with you if you are ok with those as they are at the moment with the explanation that was provided.

  1. change in the packages/core/src/util/resolvers.ts - I have added the reason why is that but I haven't yet resolved the conversation
  2. the changes to the :key to include the size of the layout items is still there at least until there is some support from the core to know when the uischema is changes to use the proper key that will work on all changes to the layout data - e.g. reordering and etc.
  3. the issue where when we want to clear an input that is part of the additionalProperties (e.g. dynamic) and the type is an enum that we use an empty string as a reset value - not sure at the moment how to handle that one with a valid enum value since clearing does not necessary means to select any of the valid values from the supported enum set. Before that this change was not needed but then we were having an issue when we wanted to set the JSON as a data and that to be reflected by the UI - e.g. removing a dynamic field from the JSON and applying that to the form was not having an effect - that is why this change with what to set the value when the control clears the value was needed

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.

3 participants