Giving an UI option format for oneOf [react]

General
1

Well, let’s say there is a schema like this:

const schema = {
  type: "object",
  title: "Auth.js Configuration",
  properties: {
    providers: {
      type: "array",
      items: {
        oneOf: [
          {
            type: "object",
            properties: {
              type: { const: "Credentials" },
              authorizeFunction: { type: "string" }
            }
          },
          {
            type: "object",
            properties: {
              type: { const: "Google" },
            }
          },
          {
            type: "object",
            properties: {
              type: { const: "Github" },
            }
          },
        ]

      }
    }
  }
}

How can I format options with UI schema to authorizeFunction in this schema?

2

The OneOfRenderer uses the createCombinatorRendererInfos utility to render its options, see here.

The util then calls the findUISchema util which is used whenever we need to determine a UI Schema for a (sub) JSON Schema, see here.

See here for the implementation of findUISchema.

In short:

The Render of Object's Description
3

Thank you for your answer.

I have been working with your jsonforms library for about 1 month. At first, I liked the UI Schema structure that provided convenience for layout viewing. However, to be clear, at the point I have reached now, I see that simple questions do not have simple answers, that is, simple solutions.

Maybe some structures need to be reconsidered in your library. The shortcomings I see:

  • although the tester system is a nice system, it is difficult to test itself.
  • it is difficult to override some fields from a default schema, it is difficult to select custom widgets.
  • the structure is built complex, wrapping react components with…Props is outdated.
  • I see cells components as unnecessary. Here the software has to repeat itself. You write the same things once again. There could have been simple solutions to this
  • it doesn’t fully fulfill the json-schema specification. the missing points should be re-evaluated.
  • a headless json form manager would be the most logical use case. So the jsonforms logic and UI are intertwined (this is the most important item in my opinion).

So I am postponing my decision to continue with jsonforms. Good work to you.

4

Hi @cihad,

Thank you very much for taking the time to give us feedback :heart:

  • although the tester system is a nice system, it is difficult to test itself.

Could you elaborate on what you mean by “difficult to test itself”? For instance, would it be helpful if each tester could optionally have a name for easier debugging?

  • it is difficult to override some fields from a default schema, it is difficult to select custom widgets.

Could you provide more details about the challenges you faced? For example in the original authorizeFunction example it should be straightforward to implement a custom renderer/tester which checks for the authorizeFunction property in the schema instead of trying to customize just via the UI Schema.

  • the structure is built complex, wrapping react components with…Props is outdated.

We currently use the HOC pattern to separate concerns. This allows the renderer component to declare the props it needs, while the HOC maps the “form-wide state” and “dispatcher props” to those renderer props.

From your perspective, which modern pattern or implementation approach do you think would better address these concerns?

  • I see cells components as unnecessary. Here the software has to repeat itself. You write the same things once again. There could have been simple solutions to this

Each renderer set has a different approach to using cells. For instance in React Material, cells play a minor role because they are confined to the table renderer. Adopters sometimes need to repeat code across renderer and cell components when they want to customize both which is not ideal. Is that the issue which you faced too?

In React Vanilla, cells are reused within standard renderers. Adopting a cell in this case should also customize it for both the table renderer and regular renderers and no duplication should be necessary.

  • it doesn’t fully fulfill the json-schema specification. the missing points should be re-evaluated.

For JSON Schema features not commonly used in our projects, we rely on community contributions to bridge the gaps. Could you share which specific features of the JSON Schema specification were missing for your use cases?

  • a headless json form manager would be the most logical use case. So the jsonforms logic and UI are intertwined (this is the most important item in my opinion).

Conceptually we designed the library so that every invoked renderer has 100% control once it is invoked. Therefore, some code, for example the UI Schema generation for nested objects, is then also invoked by the renderer.

However JSON Forms does not need to be used that way. You can generate a full UI Schema (or UI Schema registry) before invoking JSON Forms. JSON Forms is then reduced to delegate to the corresponding renderers.

You can also manage the complete form wide state outside of JSON Forms via a custom middleware.

Some renderers keep local state, for example which category is selected in our default category renderers. This can be replaced by a custom category renderer which stores/restores the category election via an own context or the form wide state.

As this is your most important point, I’d love to understand more about your ideal workflow or architecture for a headless form manager. How do you envision it?

So I am postponing my decision to continue with jsonforms. Good work to you.

Thank you again for your thoughtful feedback and for taking the time to engage with us. I hope my response addresses some of your concerns. If you have a chance to follow up, it would mean a lot.