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	4803dec
🔍 Latest deploy log	https://app.netlify.com/projects/jsonforms-examples/deploys/692e7cecc39aba00086f9a01
😎 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: 82.798%. remained the same
when pulling 4803dec on kchobantonov:preserve-edit-data
into 6bbfbb3 on 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.