preserve the form data so when we update the additionalErrors the dat…

[kchobantonov]

…a is not reset to the initial state

[netlify]

✅ Deploy Preview for jsonforms-examples ready!

Name	Link
🔨 Latest commit	99e448e
🔍 Latest deploy log	https://app.netlify.com/projects/jsonforms-examples/deploys/6a81e9ee92046d0008fdb897
😎 Deploy Preview	https://deploy-preview-2478--jsonforms-examples.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

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

[kchobantonov]

@sdirix please review, to check the issue in the current master branch just apply the change for ExampleView.vue and then try to test the additional-errors example, e.g. change the form once it is loaded and then click on the "Add Additonal Error" button and observe that the form data is reset, then check the https://deploy-preview-2478--jsonforms-examples.netlify.app/vue-vuetify/#additional-errors

[coveralls]

coverage: 84.29% (+0.004%) from 84.286% — kchobantonov:preserve-edit-data into eclipsesource:master

[sdirix]

So the error occurs only if the user of JSON Forms:

• hands over new additionalErrors to JSON Forms component
• does not hand over an updated state of the the data

I don't think that this is a valid use case. Either the props of the JSON Forms component are "frozen" and the management is done by JSON Forms, or the props are always live. The error case is a weird mix which is not really valid.

The same issue will occur in Angular and React if only parts of the props are updated. Either they should never be updated by the user, i.e. uncontrolled variant, or they should all be updated, i.e. controlled variant.

[kchobantonov]

I understand the distinction between controlled and uncontrolled usage, but in practice consumers of JSON Forms may mix these patterns—intentionally or unintentionally—especially in larger applications with multiple state sources.
From a robustness standpoint, the component should ideally handle all variants, including partial updates.

Even if this “weird mix” is not the recommended pattern, supporting it makes JSON Forms more fault-tolerant and easier to integrate in real-world scenarios where the state flow is not always perfectly aligned with controlled/uncontrolled paradigms.

[kchobantonov]

@sdirix @lucas-koehler please also check the update where the generated schema and uischema are properly regenerated when the data is changes - please check this example dynamic when if you change the data to a number and save then the ui will be updated accordingly - in previous versions that was not true.

[kchobantonov]

@sdirix please review

[kchobantonov]

@sdirix @lucas-koehler please review

[lucas-koehler]

Hi @kchobantonov ,
Thanks for the updates! I have some comments inline unrelated to the setting of this.dataToUse = newEvent.data;.

I am still a bit concerned about this:

• It makes the data propagation less intuitive:
  • In the controlled case, the data is set to dataToUse again after it has already been updated. Granted, this does not trigger an additional invocation of coreDataToUpdate().
  • In the uncontrolled case, this triggers coreDataToUpdate an additional time without it being needed. This has a possible performance penalty because it invokes the middleware again
  • In the mixed case, it triggers the coreDataToUpdate like in the uncontrolled case. From a data point of view that should also not be necessary because the data is uncontrolled. Granted, this is acceptable considering the issues that this tries to fix.

As this does make the state handling less intuitive and lowers performance in uncontrolled mode as far as I can tell, I am leaning towards not introducing supporting this mixed case.

Do you have a concrete use case in mind where this is necessary? For a diffuse robustness increase, I prefer to not introduce this because consumers can always control the data in the component rendering the form. Even if the state handling is more complex for other properties.
We can of course add this to the documentation though.

[kchobantonov]

Hi @kchobantonov , Thanks for the updates! I have some comments inline unrelated to the setting of this.dataToUse = newEvent.data;.

I am still a bit concerned about this:

• It makes the data propagation less intuitive:

  • In the controlled case, the data is set to dataToUse again after it has already been updated. Granted, this does not trigger an additional invocation of coreDataToUpdate().
  • In the uncontrolled case, this triggers coreDataToUpdate an additional time without it being needed. This has a possible performance penalty because it invokes the middleware again
  • In the mixed case, it triggers the coreDataToUpdate like in the uncontrolled case. From a data point of view that should also not be necessary because the data is uncontrolled. Granted, this is acceptable considering the issues that this tries to fix.

As this does make the state handling less intuitive and lowers performance in uncontrolled mode as far as I can tell, I am leaning towards not introducing supporting this mixed case.

Do you have a concrete use case in mind where this is necessary? For a diffuse robustness increase, I prefer to not introduce this because consumers can always control the data in the component rendering the form. Even if the state handling is more complex for other properties. We can of course add this to the documentation though.

Yes I have a specific case in my camunda-jsonforms-plugin project where when the form is submitted then if the backend determines that some of the fields is not valid because of some runtime constraints then I'm returning back to the UI additionalErrors so those can be rendered on the UI to represent the server side validated fields but when I set the additionalErrors that triggers the setting of the forms data and etc. which defacto reverts my changed data to whatever I had on the first load which is definitely not what I wanted since that will not display the data in the form as it was before submitting that. It is given that I can by pass that (in the example project even I do capture the data and preserve that) but since that looks like a bug to me to be honest I wanted to see that in the core itself instead of me handling that in multiple places like the vuetify3 demo app in the jsonforms project, in my camunda-jsonforms-plugin in the jsonforms-vuetify-webcomponent project and so on.

[kchobantonov]

@lucas-koehler thanks for the review - please check my comments

[sdirix]

I think we just have a clash of expectations here.

@kchobantonov is treating data like a defaultValue in React. Handing over an initial value and never expected to update it. We, the JSON Forms team, treat data like a controlled prop which needs to be updated.

This is additionally complicated by the fact that data is optional. The user could expect that if they never handed in data and only update the additionalErrors, that they still do not need to update their data. But this is not the case currently.

I think it would be good to clearly differentiate the two behaviors and therefore expectations. For this we can introduce two new props, modelValue which is the usual name in Vue 3 with v-model support, and defaultValue for the "hand over once and never update" case. Accordingly we will then behave within the JSON Forms component. We keep data as it is currently for backward compatibility, i.e. treat it the same way as modelValue.

Alternatively we could also not create a new modelValue prop but just offer an update:data event for custom v-model:data support. In fact that's even better to avoid introducing a redundant variable.

Does this make sense for everybody? @lucas-koehler What do you think? @kchobantonov would you be willing to implement this?

[lucas-koehler]

@sdirix Thanks for the explanation. I agree with your sentiment. Both suggested solutions are fine with me but I prefer the second one to keep the API of the JSON Forms component concise. I.e.:

Alternatively we could also not create a new modelValue prop but just offer an update:data event for custom v-model:data support. In fact that's even better to avoid introducing a redundant variable.

[sdirix]

Yes, I think we need to cleanly differentiate between "controlled" data and "uncontrolled" data. This becomes even more clear now with the schema regeneration.

Alternative for the schema generation: We could also think about NOT handling the schema regeneration within JSON Forms and expecting the caller of JSON Forms to remount us, e.g. via a key, so we don't need to handle that case within JSON Forms. However I would be fine to keep it within JSON Forms but only for the "controlled" mode, so that we don't regenerate on simple user edits.

[kchobantonov]

Yes, I think we need to cleanly differentiate between "controlled" data and "uncontrolled" data. This becomes even more clear now with the schema regeneration.

Alternative for the schema generation: We could also think about NOT handling the schema regeneration within JSON Forms and expecting the caller of JSON Forms to remount us, e.g. via a key, so we don't need to handle that case within JSON Forms. However I would be fine to keep it within JSON Forms but only for the "controlled" mode, so that we don't regenerate on simple user edits.

Yes, I think we need to cleanly differentiate between "controlled" data and "uncontrolled" data. This becomes even more clear now with the schema regeneration.

Alternative for the schema generation: We could also think about NOT handling the schema regeneration within JSON Forms and expecting the caller of JSON Forms to remount us, e.g. via a key, so we don't need to handle that case within JSON Forms. However I would be fine to keep it within JSON Forms but only for the "controlled" mode, so that we don't regenerate on simple user edits.

There are now checks for schema-less usage: when the data prop changes, we compare the newly generated schema with the current one and only update the schema/UI schema if the data structure actually changed.

[kchobantonov]

@sdirix Do we still plan to merge this PR, or have we decided not to pursue this approach?

I'm asking because, besides the additionalErrors issue with form data, this PR also includes a fix for schema generation. Instead of:

return gen.schemaObject(instance);

it uses:

return gen.property(instance);

which is more correct, as it allows the generator to properly detect whether the input is a simple type, an array, or an object and generate the appropriate schema.

If we're no longer considering merging this PR, I can create a separate PR containing just the schema generation fix and then close this one.

[sdirix]

I will re-review this PR today. Let's see.

[sdirix]

@sdirix Do we still plan to merge this PR, or have we decided not to pursue this approach?

I'm asking because, besides the additionalErrors issue with form data, this PR also includes a fix for schema generation. Instead of:

return gen.schemaObject(instance);

it uses:

return gen.property(instance);

which is more correct, as it allows the generator to properly detect whether the input is a simple type, an array, or an object and generate the appropriate schema.

If we're no longer considering merging this PR, I can create a separate PR containing just the schema generation fix and then close this one.

@kchobantonov I re-reviewed everything today, including testing the behavior in the Vuetify dev app. Most of it is in good shape and I would recommend to merge it.

• The generateJsonSchema fix is correct and now well covered by tests.
• The generated-UI-schema fallback works. We would just like it moved into generateDefaultUISchema itself so React and Angular benefit as well.

The one part we don't want to merge as is: this.dataToUse = newEvent.data. It silently changes the semantics of the data prop for all Vue users and makes Vue diverge from React and Angular. As I wrote before we need to cleanly differentiate between "controlled" and "uncontrolled" data.

Concretely that means: keep the data prop semantics as they are and add the update:data event from the previous discussion, so v-model:data works out of the box. The additionalErrors use case is then solved by binding v-model:data, without JSON Forms mixing controlled and uncontrolled state internally. I left inline comments with the details.

If you'd rather land the schema generation fix quickly, splitting it into its own PR is fine with us and should merge fast. But if you're up for the update:data change, we can just as well finish everything here. Thanks again for driving this!

[kchobantonov]

@sdirix all reported issues are now addressed - please review.

[EclipseSourceAI]

Note

Autonomous AI review.

This review was done by an AI agent and therefore may contain mistakes. Feel free to ignore any comment you disagree with. Noting why helps, since replies are read and taken into account in follow-up reviews.

Resolving all AI comments does not lead to an automatic approval. A maintainer still needs to review and sign off on the overall architecture and design.

To get an updated review after pushing changes, a maintainer may re-request a review from this account.

Running in Eclipse Enclave, submitted via review-guard-mcp

Fixes the additionalErrors resetting form data in the Vue JsonForms component by adding an update:data event for v-model:data support, plus schema/uischema regeneration when the data prop changes externally in schema-less mode. Also carries two @jsonforms/core generator fixes: generateJsonSchema now handles non-object roots (primitives, arrays, undefined, null) via gen.property, and generateDefaultUISchema no longer returns null.

All previous review points from sdirix and lucas-koehler look addressed: the dataToUse sync is gone, the uischema fallback moved into the generator so React and Angular benefit, echo detection compares against jsonforms.core.data, and the generator tests cover the new cases.

Verified locally: build and lint clean, all package tests pass (the angular-material failure in my first run was a missing CHROME_BIN, not the PR). I also drove the Vuetify dev app: the additional-errors example keeps edited data across repeated "Add additional error" clicks, #dynamic regenerates from Name to Id on external data change, and root-level primitive data (42, "hello") renders a single working control with no console errors.

Where to focus: the new data watcher in packages/vue/src/components/JsonForms.vue, specifically the !this.schema guard (breaks the legal schema: false case, verified), and whether the two public core generator behavior changes should get MIGRATION.md entries under the existing 3.9 section. The rest of the inline comments are smaller cleanups.

[kchobantonov]

@sdirix now the EclipseSourceAI comments/review are resolved with the last commit