additionalErrors usage from within Renderers/Cells (v3.0.0)

We are currently testing the new 3.0.0 release, especially the new prop additionalErrors.
We understood that it can be used to gather and merge errors for example from the APIs, or in general external ones, but we were wondering if it suits also updates coming from within the form itself.

Can I use it in a custom Renderer of mine instead of updateErrors, if I want to manage some additional ones?

The way I manage to make it work was providing a state and its setter outside JsonForm, providing both via Provider and managing the errors inside each interested Renderer.

  const [additionalErrors, setAdditionalErrors] = useState<ErrorObject[]>([]);

  return (
    <JsonFormsAdditionalErrorsProvider value={{ additionalErrors, setAdditionalErrors }}>

The problem arise when I try to apply both the value change and the validation, which I currently do as follows:

  const onChange = (path: string, value: any) => {
    handleChange(path, value);

where setAdditionalErrors is the state setter coming from the Provider, and getAdditionalErrors derives the errors from the original, after the evaluation.
The effect is that the value update is not correctly seen by JsonForm, and I have to wrap it in a setTimeout to make it work:

  const onChange = (path: string, value: any) => {
    handleChange(path, value);
    setTimeout(() => setAdditionalErrors(getAdditionalErrors()), 200);

So I’m wondering if I’m correctly using additionalErrors or maybe it’s not meant to be used inside my Renderers.
In general, with this new version what is the suggested way to manage custom error validation from Renderers and Cells, when you cannot rely on the json schema only?

Could you advise please? Thanks

Hi @pietro-marrone,

That’s an interesting use case which we didn’t account/plan for when we designed this feature.

The feature is intended to mix in errors coming from a different source which can’t be handled within the frontend. For example when there are checks which can only run on the server/cloud but still should show up as errors within the form after submit.

We also foresaw the use case of the user wanting total control over the displayed errors. In that case the form can be run in validation mode "NoValidation" and the user can just feed their own errors in whenever they are informed about a data change.

In your scenario the error is determined within the renderer but also handed back to JSON Forms within the same pass as the internal form data is updated. In general this should also work. If you run into problems here then this is likely caused by our rendering and debouncing optimizations which did not take such a scenario into account. My guess is that because setting the additional error will also lead to a rerender of JSON Forms something does not happen in the expected order. Using a timeout will naturally fix that as it’s the same scenario as an additional error coming from some other source.

The effect is that the value update is not correctly seen by JsonForm,

What exactly is the consequence? Does your input not update? If you can push an executable branch somewhere then it will be easier to understand what exactly is going wrong.

In general I’m wondering why you chose this approach. If you need more specialized validation then a typical approach is to just add a custom validator to AJV. In case you don’t care about collecting all errors in one place you could also just render the error within your renderer without updating some outside state. Can you elaborate on the use case you want to solve?