Open Bols opened 4 months ago
Hi @Bols,
Thanks for the interesting suggestion. I can see how using a building pattern could result in more readable code in case that is a use case which comes up often.
I'm not sure it's worth to integrate such a builder into the core framework, especially as we don't have the use case ourselves. It should not take much code to write such a builder if one is needed, as you did yourself. Can you share how many lines of code the builder POC took?
The "visible" rule can be coded in javascript, which is a lot more expressive
That is an interesting feature, not really related to the builder pattern. As JSON Forms just consumes a Javascript object (and not a JSON string), you can already support this feature via custom renderers.
However integrating a functional visible rule could be useful for more users. So instead of the schema based rule, we could officially also support a functional one in which we just hand over the current parameters, e.g. schema
, data
, path
, uischema
etc.
Is this something which you actively use? What use cases do you cover here which were not expressible via our currently supported schema-based rules?
Is your feature request related to a problem? Please describe.
I like the simple idea of jsonforms, but the uischema json-configuration seems to be verbose, and includes a lot of property-references, and the and/or-language of the visibility/enablement is very limited. I realize the choice of json for this is LITERALLY in the project name, but I belive a programmatic approach may be a better solution.
Describe the solution you'd like
I have been working on an alternative approach. This approach is also typesafe, if a typescript-version of the schema is generated (typically using plugins during build-time). I now have a runnable proof-of-concept, where the uischema is programmatic:
Advantages:
The POC is unfortunately in a code base that can not be shared for legal reasons, but I would be happy to provide more info if you find this to be an interesting approach
Describe alternatives you've considered
Alternative approaces would be to keep this POC local to our organization only, or create a new standalone open-source project when we have something that can be shared
Framework
No response
RendererSet
No response
Additional context
No response