Support for additionalProperties

General
1

Does jsonforms support additionalProperties? I’ve tried setting ‘additionalProperties: true’ as well as specifying an additionalProperties schema, but no data is rendered and there’s no UI to add props.

2

Hi @dieseldjango,

JSON Forms has barely any support for additionalProperties by default as there is not really a semantic meaning for this field (for a form rendering framework). So any implementation we could do for this will probably also not reflect your use case and therefore not be useful. The same is true for patternProperties.

However you could definitely implement a custom renderer which reacts on elements with additionalProperties and does something useful with it. If you need guidance, please define how you would see the UX flow here for additionalProperties.

3

Thanks for the response @sdirix. I’m already looking at patternProperties, so I’ll look into additionalProperties too.

4

Howdy chums. I’m looking to build a form renderer for a configuration file for a pre-existing OSS project. That project wants configuration in YAML but since YAML ↔ JSON, I think I can translate my story to use JSON Forms. The format of the input data is described in a README. One of the example structures within has the following as example YAML:

row_filters:
  NONE:
    filter_sql_expr: |-
      True

  DATA_TYPE_EMAIL:
    filter_sql_expr: |-
      contact_type = 'email'

As I studied this, I felt that the corresponding JSON Schema would be:

row_filters:
  type: object
  additionalProperties:
    type: object
    properties:
      filter_sql_expr:
        type: string

The way I read this is that a row_filters object can have properties with any property name where the structure of that property is defined (an object with a single property called filter_sql_expr).

The reason for this post is to puzzle on the comment from Stefan which said:

JSON Forms has barely any support for additionalProperties by default as there is not really a semantic meaning for this field (for a form rendering framework).

From what I think I’m seeing is that there is a powerful form filling application here. I’m imagining a group which has a header of row_filters and some kind of “add” button to add children of row_filters where each child is itself a structure. The name of the child will be entered by the user and will be the name of the property. I’m wondering if I’m missing some deeper thought that makes us think that there is either a better way of achieving the goal or is this too special a case for additionalProperties support.

5

Hi @kolban-google,

From what I think I’m seeing is that there is a powerful form filling application here. I’m imagining a group which has a header of row_filters and some kind of “add” button to add children of row_filters where each child is itself a structure. The name of the child will be entered by the user and will be the name of the property. I’m wondering if I’m missing some deeper thought that makes us think that there is either a better way of achieving the goal or is this too special a case for additionalProperties support.

Your interpretation on how a UI for this could work is perfectly valid. It’s basically the same use case as patternProperties, just that patternProperties has more restrictions on the property name.

The reason for this post is to puzzle on the comment from Stefan which said:

JSON Forms has barely any support for additionalProperties by default as there is not really a semantic meaning for this field (for a form rendering framework).

From what I think I’m seeing is that there is a powerful form filling application here.

I was probably too generalizing here as I was mainly thinking about additionalProperties: true where it’s hard to provide some specific UI. When additionalProperties has a well definied structure, rendering an array-like UI with an additional input to specify the “id” (i.e. property name) makes sense to me.