React-jsonschema-form: Interest in extracting ui and schema mapping into shared dependency library?

[jejacks0n]

This is a question not an issue.

I'm working on a similar project (using vue) and have seen a couple of examples of the UISchema concept implemented now. Due to this, my priorities have shifted to include being consistent with one or more of those other projects and so extracting logic that handles "widget" mapping seems to be a high priority given those goals.

I'm sure we can all agree there are some complexities around mapping JSON Schema properties to HTML tags like input type= and others like textarea, and select for instance -- while also making this nicely declarative and extensible for developers using the library.

After doing a first pass and then thinking through the concepts further, my plan has shifted to adapting the logic that's available within this library into a more general case dependency library that can take a JSON Schema and build that into a consistent and flexible UI mapping.

What are the teams thoughts on collaborating on this or having a conversation with other developers to see if there's a way to gain some consistency and definition around the UISchema concept that seems to have a couple of flavors at the moment?

[epicfaace]

Thanks for your note @jejacks0n , interesting idea. Essentially, are you thinking of creating a new standard for uiSchema? It would be good if you could send a link to other implementations of the uiSchema concept so we can see how they share things in common.

Additionally, another proposal that has been floating around with this library is doing away with uiSchema entirely and embedding it into the JSON Schema: https://github.com/mozilla-services/react-jsonschema-form/issues/701

[jejacks0n]

I'm not opinionated on an approach to the UI Schema challenge yet, but have ideas. I tend to agree with it being part of the JSON Schema definition for simplicity when nothing complex is needed, and then some other schema concept for when you want to do something more complex maybe?

I don't want us to define and document a schema around UI because that's just asking for a load of work that most developers won't enjoy defining, nor using. The effort can rather be focused around having a consistent and UI agnostic library that resolves the schema from JSON Schema into an alternative schema that could also be provided independently.

Example 1: FormSchema Native adds the concept of UI to JSON Schema. This library uses an attrs key. I appreciate this one the most as a developer who wants to do something simple and doesn't want to be verbose. In this instance, let's just get the job done and render a form, and yes I'd like to customize some aspects please.

__JSON Schema__

{
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "maxLength": 80,
      "attrs": {
        "placeholder": "Full Name"
      }
    }
  }
}

Example 2: vue-form-json-schema has an example of having a comprehensive "layout" UI Schema. It accepts a JSON Schema to define the model, and then an array of objects as the UI Schema. It uses the UI Schema to build out components (or tags) and then resolves back to the JSON Schema by the model key.

__JSON Schema__

{
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "maxLength": 80,
    }
  }
}

__UI Schema__

[
  {
    "component": "div",
    "fieldOptions": {
      "class": "row"
    },
    "children": [
      {
        "component": "input",
        "model": "name",
        "fieldOptions": {
          "class": ["form-control"],
          "on": ["input"],
          "attrs": {
            "placeholder": "Full name"
          }
        }
      }
    ]
  }
]

JSONForms has a similar concept but is clearly very different structurally. This library takes a similar approach to JSONForms but is also structurally different.

__JSON Schema__

{
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "maxLength": 80,
    }
  }
}

__UI Schema__

{
  "type": "VerticalLayout",
  "elements": [
    {
      "type": "Control",
      "scope": "#/properties/name"
    }
  ]
}

It seems valuable to me to have the capability to have UI defined easily at the JSON Schema level, or in a separate UI Schema that may not be structurally similar to the JSON Schema. For instance, I may want multiple columns for some of my form elements (city, state, zip). How can we allow more complex layouts and also take into account that I may have globally declared components and might want to use them?

Global components you say? Web Components and Vue implement similar concepts for globally registered components. React doesn't support that at the moment (that I'm aware of), but libraries that implement this can provide a resolver pattern or something that permits the same architecture if they wanted to.

This allows for UI Schemas to be defined for different systems if that makes sense for a library -- e.g. web vs. native. It also loosely allows for extracting the default UI Schema from the JSON Schema definition.

The library I'm proposing is based on Example 2, and is one that could take a JSON Schema and extract the UI definition attributes when present, and convert that into this alternative UI Schema that I'm also proposing. That way any library that implements a UI on top of JSON Schema can simply share that base concept, and if it's a javascript project, the actual code.

The UI Schema would more or less be:

[
  {
    "component": "input",
    "scope": "#/properties/name",
    "props": {
      "placeholder": "Full name"
    },
    "children": []
  }
]

All of the examples included here would be supported with some effort on their maintainers part. Any library that utilized it would only be concerned with its own UI components, providing hooks for resolving default values and resolving (where needed) global components.

[jejacks0n]

Couple things to note -- the use of arrays and not objects because of ordering issues that can arise from objects (https://stackoverflow.com/questions/5525795/does-javascript-guarantee-object-property-order). Generally the object order doesn't matter when you're dealing with JSON Schema, but in the case of a UI it probably does. Open to ideas about that though because I thought the use of arrays was silly until considering why.

I'm not at all stuck on the naming of the keys either.

Inside JSON schema this might look like the following:

{
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "maxLength": 80,
      "ui": {
        "component": "input",
        "props": {
          "placeholder": "Full name"
        }
      }
    }
  }
}

Or a more complex structure / layout.

{
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "maxLength": 80,
      "ui": {
        "component": "horizontal-layout",
        "children": [
          {
            "component": "label",
            "props": {
              "title": "Enter your full name"
            }
          },
          {
            "component": "input",
            "scope": "#/properties/name",
            "props": {
              "placeholder": "Full name"
            }
          }
        ]
      }
    }
  }
}

[epicfaace]

@jejacks0n thanks for the writeup.

I like Example 1, in which the UI attributes are embedded in the schema itself. I'm still not sure why exactly we would need a separate UI Schema, as in Example 2.

It seems valuable to me to have the capability to have UI defined easily at the JSON Schema level, or in a separate UI Schema that may not be structurally similar to the JSON Schema. For instance, I may want multiple columns for some of my form elements (city, state, zip). How can we allow more complex layouts and also take into account that I may have globally declared components and might want to use them?

Global components you say? Web Components and Vue implement similar concepts for globally registered components. React doesn't support that at the moment (that I'm aware of), but libraries that implement this can provide a resolver pattern or something that permits the same architecture if they wanted to.

This allows for UI Schemas to be defined for different systems if that makes sense for a library -- e.g. web vs. native. It also loosely allows for extracting the default UI Schema from the JSON Schema definition.

The library I'm proposing is based on Example 2, and is one that could take a JSON Schema and extract the UI definition attributes when present, and convert that into this alternative UI Schema that I'm also proposing. That way any library that implements a UI on top of JSON Schema can simply share that base concept, and if it's a javascript project, the actual code.

I guess the concept of "UI Schemas ... defined for different systems" and "globally declared components" is already taken care of by rjsf's customization of widgets, fields, and templates (which can now all be declared using a single withTheme HOC). In that sense, it may be more than enough just to do away with UI Schema altogether, and only allow for UI changes in the schema itself. Or do you think it would be beneficial to move this all over to the UI Schema structure you were proposing?

[loganvolkers]

A couple things on this issue:

1) There is another very popular JSON Schema editor maintained mostly by @pmk65 here: https://github.com/json-editor/json-editor

2) The problem with embedding UI Schema into the JSON Schema is that it can result in non-valid JSON schemas that won't pass validation. This was a problem with json-editor/json-editor

3) The benefit of separating UI Schema is that you can create a separate UIs for the same JSON Schema. 1 JSON Schema and 2 UI Schemas --> 2 forms.

Items 2 and 3 are why we migrated to using this project instead of the json-editor listed in 1.

[loganvolkers]

Also if you want to talk about getting a band together, and centralizing some code, there's also this popular Angular project: https://github.com/json-schema-form/angular-schema-form

[jejacks0n]

I agree @loganvolkers, and thanks for contributing your thoughts.

Generally, I like the brevity of putting the UI definition into the JSON Schema in simple cases, but the goal is to think of it holistically which means that templates, widgets and fields are great, but don't feel like the final iteration. This is where I'm the most uncertain however -- maybe it's on the library to provide template and layout capabilities which might be custom to the implementation. Which would mean a separate UI Schema concept isn't needed.

Don't get me wrong, I think yet _another_ markup language is dumb, all I'm trying to do is come up with a reasonably useful object structure that can be reduced down into a markup language which ultimately I now view as "components" (which could map to a tag if needed). The same thing can be said of a lot of rendering systems, so I'm feeling pretty comfortable with the concept in simple terms.

Anyway, thanks again for chiming in and sharing opinions everybody. I'm still thinking on this for sure.

[loganvolkers]

I agree @jejacks0n that the UiSchema concept might be custom to the implementation. React, Vue, Web Components, Angular, etc all have specific ui quirks that will require custom UI options.

It might be better to think of UiSchema as "UI options" instead of thinking of it as an actual "schema". I would argue again that JSON Schema reflects the shape of the data, but the UiSchema reflects the shape of the form.

I've found working with the UiSchema powerful because you can provide components directly "ui:Widget": require("./MyComponent") instead of requiring global namespacing "ui:Widget": "MyComponent".

UiSchema isn't required to be serializable JSON it can be and often is a javascript object. It allows for passing in context, callbacks, and other things that are specific to how the form submits or connects to databases for select lists or extra non-schema validations, which has very little to do with JSON Schema.

I think that there is a lot of room for consolidation in all these JSON Schema form libraries. Centralizing core parts of UiSchema might be a good path. Extensible UISchema to allow for per-library customization I think needs to be accepted as a good thing.

[timkindberg]

Really wish this was a thing right now.

I think there needs to be a framework-agnostic and headless jsonschema-ui library.

The libs job would not include ANY UI rendering of any sort, it would simply return the data needed to render the UI. This coupling of bootstrap to rjsf is hurting it bigtime. A Bootstrap theme should be another npm package built on top of this headless package.

How much effort would be involved to decouple the UI rendering from the schema parsing?

[loganvolkers]

@timkindberg if you need a js-only version of this library that support arbitrary rendering see https://github.com/jdorn/json-editor

• I don't see the decoupling of React with the UiSchema stuff in the package.
• There's already ajv for validation.
• You could in theory break out the majority of utils.js as it's own package without it depending on React.

[gullitmiranda]

1. The problem with embedding UI Schema into the JSON Schema is that it can result in non-valid JSON schemas that won't pass validation. This was a problem with json-editor/json-editor
   ...
   Items 2 and 3 are why we migrated to using this project instead of the json-editor listed in 1.

@loganvolkers, a question about the separate UI Schema. How do you deal with ui that differs based on conditions?

simple examples that the ui changes according to conditions:

• not having all fields
• change the order

[loganvolkers]

That is my number one complaint with UI schema is that it isn't formally
defined and doesn't cover all cases.

For example I've been looking to provide a visual designer to help people
set up their ui schema... But you can't do it!

You can't use schema form to edit a uischema object. The namespacing of UI
schema prevents defining properties that overlap with existing properties.

The fundamental problem is that uischema tries to be less verbose that Json
schema, but it cuts out keywords like properties and
additionalProperties and oneOf and as a result can't be used for all
schemas.

Until you can define a uischema that provides a nice experience for editing
itself, then it's not a good standard. By comparison JSON schema has proper
metaschemas in every version.

Sorry if you were hoping for better news.

On Thu, Jan 28, 2021, 10:44 AM Gullit Miranda [e-mail]
wrote:

>

1. The problem with embedding UI Schema into the JSON Schema is that
   it can result in non-valid JSON schemas that won't pass validation. This
   was a problem with json-editor/json-editor
   ...
   Items 2 and 3 are why we migrated to using this project instead of the
   json-editor listed in 1.

@loganvolkers https://github.com/loganvolkers, a question about the
separate UI Schema. How do you deal with ui that differs based on
conditions?

simple examples that the ui changes according to conditions:

• not having all fields
• change the order

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rjsf-team/react-jsonschema-form/issues/1318#issuecomment-769294168,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAI2PXRJGWFXLJBC3AIWOETS4GV7HANCNFSM4HWKZMTQ
.