Programmatic builder pattern UISchema alternative

[Bols]

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:

export const eksempeluischema = new VerticalLayoutDef<any, EksempelDataTo>((add) => {
    add.field("bareBokstaver", new ControlDef());
    add.field("jaNei", new ControlDef());
    add.container(new HorizontalLayoutDef((add) => {
        add.field("tall", new ControlDef()).visible((c) => c.getParent().jaNei);
        add.field("harListe", new ControlDef());
      }
   ));
}

Advantages:

• This is a much more compact solution (replaces 30 or so lines of json, a lot more if the rules are more complex)
• The "visible" rule can be coded in javascript, which is a lot more expressive
• The configuration can be parameterized, so you can add conditional logic and have different variants
• It is easy to reuse sub-uischema-definitions, making a more modularized design
• This approach is also typesafe (meaning it will give a compilation error if any of the referenced field-names are not in the actual schema, so typos and wrong references should not be a problem.

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

[sdirix]

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?