Interest in extracting ui and schema mapping into shared dependency library?

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?

[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]

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.