jsonforms

jsonforms copied to clipboard

Is your feature request related to a problem? Please describe.

When using the various renderer libraries (material-renderers, for example) it feels like a lot of functionality is being left behind. The renderers interface with components that have lots of features, and support many use cases with a variety of different props/arguments.

It's a shame that we aren't able to access all of this functionality and pass all of these args from the ui schema to the underlying components. I suspect this was perhaps intentional as to not clutter the ui schema, to keep it simple, and, maybe more importantly, to keep it universal. But what this means is that the functionality in the ui schema ends up being such a small subset of your ui component library's functionality.

Describe the solution you'd like

Cluttering the schema with every prop from every renderer would definitely not be ideal. It would also ruin the dream of the ui schema being decoupled from the ui renderer. However, isn't there a simple solution to all of these problems?

Consider the addition of a single key (per renderer set) on the ui schema options, one which would be passed directly through and spread onto the underlying components, eg

// uischema.json
{
  type: 'Control',
  label: 'Start date',
  scope: '#/properties/startDate',
  options: {
    material: { // this should match the name of the renderer set it will apply to
      // if the renderer renders any of these components, it will spread the following objects value onto them
      TextFieldProps: { ... },
      DatePickerProps: {
        showTodayButton: true
      },
      // ...etc
    }
  }
}

From the renderer side, the diff would also be minimal. The above example could be implemented like:

https://github.com/sarink/jsonforms/pull/1/files#diff-678df4b42a209e09d93f6f548c65e7aeb3eaff2e38448d54aab0396529a93a61

Describe alternatives you've considered

The only real alternative to this problem is to write your own custom renderer and add custom ui schema options. In the case of needing to add just one prop (eg material-ui's showTodayButton on the DatePicker), it is pretty unfortunate to have to fork the existing renderer, add one line, then maintain it forever.

Framework/RendererSet

All

Hi @sarink, this is an interesting suggestion. We actually have something like this already in place for the @jsonforms/vue2-vuetify renderers where you are able to set vuetify props via the UI Schema options.

My guess to why this was not requested yet and why we ourselves are usually not using such a mechanism is that typically every user with some advanced UI needs just builds their own renderer set anyway: In practice any special UI needs are usually dealt with custom renderers and the UI Schema is often reduced to layouting and to handle rules.

However I can definitely see this being useful. Note that for Material UI specifically most use cases can already be dealt with the Material UI theme support which already lets you define default props for all Material UI elements. As you usually want to style not only JSON Forms but also the remaining application, this would be the more natural way.

The remaining use case for React Material would therefore be for one-off props or to overwrite props which are already set by JSON Forms and can therefore not be set via the theme support. Is this one of the use cases you have?

Hey @sdirix , yes, exactly. I agree that the material theme options will get you pretty far, but sometimes it doesn't make sense (or isn't possible) for a one-off prop. Also, as you mentioned, I see this concept being useful for other renderer sets, not just material.

I'm happy to submit some PRs if you and the team think it's a worthwhile addition to the library!

Yes, I think it would make a good contribution and we would very likely merge it. If you'd like you can showcase the concept with a Draft PR for 2-3 renderers for a feedback round before doing a full contribution to minimize the risk.

Note that you'll also need to define a behavior for when some props are already defined via the form-wide config (i.e. merge the props or completely replace them).

@sdirix can you create another base branch based on the v2.5.2 release tag?

I have a PR ready, but based it on v2.5.2, as master isn't completely stable yet, and jsonforms v3 is listed as only beta.

Once there is a new base branch so I can submit my PR, if it is approved and merged, I will then also make a second PR for v3 that goes into master. But, since jsonforms v3 is using material-ui v5, it will have to be separate and different.

I suspect a lot of folks will be stuck on material-ui v4 for awhile (and consequently jsonforms v2.5) as that upgrade introduces breaking changes and is quite time-consuming to refactor. Is your plan to maintain both v2.5 and v3 in parallel for awhile?

Ok, I was able to get master to run locally. But there is still the open question of whether or not 2.5 (which uses material-ui v4) will continue to be maintained? I'd like to merge these changes into both 2.5 and 3.0. What are your thoughts @sdirix ?

Hi @sarink,

I suspect a lot of folks will be stuck on material-ui v4 for awhile (and consequently jsonforms v2.5) as that upgrade introduces breaking changes and is quite time-consuming to refactor. Is your plan to maintain both v2.5 and v3 in parallel for awhile?

The JSON Forms project is already spread a bit thin supporting 3(+1) bindings and 5(+1) renderer sets. Our plan is to stay up to date with the latest versions of our dependencies within a reasonable time frame. We don't plan to support older versions of our dependencies or add additional bindings / renderer sets for now.

So no, we don't plan to maintain the 2.x range going forward.

I have a PR ready, but based it on v2.5.2, as master isn't completely stable yet, and jsonforms v3 is listed as only beta.

JSON Forms v3 is listed as beta but it's almost done. The release of v3 is soonish and 30% of our community already migrated. Please post more information about your build issues in #1895 so we have a chance to fix it. Note that the CI builds run perfectly fine.

Ok, I was able to get master to run locally. But there is still the open question of whether or not 2.5 (which uses material-ui v4) will continue to be maintained? I'd like to merge these changes into both 2.5 and 3.0. What are your thoughts @sdirix ?

As mentioned above we don't plan any additional 2.x release. Integrating a new feature for 2.x would not only involve the work of reviewing and iterating on an eventual pull request but also include the QA and release related efforts we do for all stable releases. On top of that our internal projects using JSON Forms switched to 3.0 for a long time now, so this additional internal testing would also be missing for such a release. At the moment I can only imagine a new release on the 2.x train as part of our professional support offerings.

In general we did some major improvements for 3.0. For some information about that, see this discussion on our board. I would definitely recommend the upgrade.

@sdirix is it really realistic to expect the whole community to migrate to material-ui v5 that fast? Is there any possible way to run jsonforms v3 with material-ui v4?

The latest version of JSON Forms 3.0 with Material v4 is 3.0.0-alpha.2. However it's alpha so not all features of 3.0 are included.

As mentioned in a previous post, our plan is to stay up to date with the latest versions of our dependencies within a reasonable time frame. Material v5 is already 6 months old. Updating to it as part of JSON Forms 3.0 to indicate breaking changes makes sense.

Of course users can stay with JSON Forms 2.5.2 for their Material v4 projects if they like to. It's definitely not a bad version, it will just no longer be updated by us unless it's wished for and prioritized by our paying customers.