We are doing a complex project, in which we work with the AFD SIVI standard (requests & responses), and we are having to deal with arrays a lot.
The main problem is, that often an array is just one item, and we don’t want to complicate our UI schemas with relative paths and nested arrays. Using an index would be amazing.
Take the following fictive scope as example to get a view on how much we would have to nest elements:
/properties/agreement[0]/properties/policy[0]/properties/party[0]/properties/financialInformation[0]
As you could see, using an index of 0 would remove about 3 times nesting elements.
Another problem occurs that in the scope I just provided, we would only want to make changes to a party in that policy which meets a certain condition. The following fictive JSONPath-like scope, for as far as we know, cannot be done with JSON Forms, but would be exactly what we are looking for:
/properties/agreement[0]/properties/policy[0]/properties/party[@.entityType == policyHolder]/properties/financialInformation[0]
That is why I would want to know how hard it is to support JSON Paths for the UI schema scopes (if we implement a custom renderer/rule/parser for it).
Is there any other simpler way of realizing what we want here that I am blinded to? Would this be interesting feature request for JSON Forms?
In short:
we would want to use indexes on arrays
we would want to add/update only certain items in an array based on a (query)condition
When a custom renderer takes over it has full control. So generally speaking, using a custom renderer you can support arbitrary behavior. However the more you deviate from the already provided bindings helpers, the more you need to do manually.
In your case you want to customize a core concept of JSON Forms: The UI Schema scope. We expect in our provided bindings that it
resolves to some sub schema of the overall JSON Schema so we can determine type etc.
that it refers to something for which we can then derive an “instance scope”. Using this we then determine the actual data, which errors apply etc.
From what I understood of your use case, you should probably not directly reuse our bindings but create your own ones. This should be relatively straightforward, copying and adapting mapStateToControlProps and the bindings boilerplate [1], [2], [3]. In your custom binding you can then implement your custom resolving / instance data determination etc. Finally you wrap your custom renderers with this new binding. For all renderers which you want to use of JSON Forms, you import their unwrapped variant and wrap them with your custom bindings. This might need some more boilerplate copying for the bindings based on mapStateToControlProps which then need to use your custom binding instead.
I would recommend to try this with a single renderer to validate the approach. Once it works and you want to go for it, the work will mostly be boilerplate copying/adapting for a few hours.
To avoid all the boilerplate manipulation we could think about a customization option for JSON Forms, for example to offer an option to use a custom resolver and/or a custom “scope to instance data converter” instead of the built-in ones. If you would like to contribute such a mechanism I would probably still recommend to create a simple custom binding example to validate this approach, for example to check whether a resolver customization is sufficient then or whether more changes are needed.
Sorry for the late reply. Thank you so much for taking the time to write this elaborate response.
We will give it a try to validate this approach when the resources and time are there.
I will definitely let the community know if I can validate this, in which case I would gladly want to help and contribute to a custom option to use a different resolver.