How to customize field choice ?

[Chnapy]

Hello,

I generate a form from JSON Schema and I want to choose which field to use for an attribute.

For example, in my JSON Schema I have this attribute check :

'check': { 
            'type': 'array', 
            'items': { 
                'type': 'string', 
                'enum': [
                    'choice 1', 
                    'choice 2'
                ] 
            }, 
            'uniqueItems': true 
        }

It render this (antd style) :

Instead that, I want checkboxes.

I know I can add this in the JSON:

            uniforms: {
                checkboxes: true
            }

But it doesn't work.
And I don't like to add uniforms properties in my JSON Schema, can I define an "UISchema" in an other file ?

I'm searching an equivalent of react-jsonschema-form for uischema, something like this:

const uiSchema = {
  "ui:widget": "checkboxes",
  "ui:options": {
    inline: true
  }
};

Thank you 👍

[radekmie]

Hi @Chnapy. It actually is working as you've described. By works, I mean that the checkboxed: true is being passed down to the component. The thing is that you've may pass it down to ListField and not SelectField. With such definition it works as wanted:

check: {
  type: 'array',
  items: {
    type: 'string',
    enum: [
      'choice 1',
      'choice 2'
    ],
    uniforms: {
      checkboxes: true
    }
  },
  uniqueItems: true
}

The other topic is the externalnalization of UI props. In general, you can do it in your project: merging or enhancing schemas is a way to go. If you have a more complex case: create your own schema bridge, probably based on an already existing one.

[Chnapy]

Thank you for your answer.

For the externalnalization I will try to create a schema bridge.

For the checkboxes I tried your sample but it didn't work:

I have a list of radio group, but I just want a group of checkboxes like that:

I made this sample with SimpleSchema in the Playground, like that:

        check: {
            type: [String],
            uniforms: {
                checkboxes: true,
                allowedValues: ['choice 1', 'choice 2']
            }
        }

So I start thinking that it's my JSON Schema that's wrong.

[radekmie]

OK, now I got it. You can go with options: ['choice 1', 'choice 2'] (on the top level, not the uniforms key) for now, but it has to be fixed. I'll get to it in some time, but as always - we are open for PRs.

[Chnapy]

Thank you it works !
If I succeed to do something good I will think about PR.

[Chnapy]

@radekmie I was wondering if there is any doc on options and uniforms attributes, I found only few examples and I don't know all i can do with these. Thanks 👍

[radekmie]

Not really. Noted for #259.

[delyanr]

Hello! Has this been worked on by any chance? I'm using JSON Schema & AntD and trying to do the following with a group of checkboxes:

{
    "type": "object",
    "properties": {
        "impact": {
            "type": "array",
            "title": "Select impacts:",
            "items": {
                "type": "object",
                "properties": {
                    "impactOne": {
                        "type": "boolean",
                        "title": "Impact One ...",
                        "default": false
                    },
                    "impactTwo": {
                        "type": "boolean",
                        "title": "Impact Two ...",
                        "default": false
                    },
                    ...
                },
            },
            "uniforms": {
                "checkboxes": true
            }
        }
        ...
    }
    ...
}

I need to have the submitted values to contain all impacts as true or false, hence using the default option. However, this is not coming out as expected (it uses list instead). Furthermore, using options does not let me achieve what I want here either.

Any suggestions, etc? Many thanks!

[radekmie]

Hi @delyanr. Using checkboxes (which is intended to be a variant of Select and Radio fields) is not going to work on a list of objects. Can you maybe describe how you'd like it to look like? Are impactOne and impactTwo exclusive on each list element?

[delyanr]

Hi @radekmie. Basically, I would like it to look like the below (if you plug into the uniforms playground):

{
    "type": "object",
    "properties": {
        "impact": {
            "type": "array",
            "title": "Select impacts:",
            "items": {
                "type": "string"
            },
            "options": [
                {
                    "label": "Impact One",
                    "value": "Impact One"
                },
                {
                    "label": "Impact Two",
                    "value": "Impact Two"
                },
                {
                    "label": "Impact Three",
                    "value": "Impact Three"
                },
            ],
            "uniforms": {
                "checkboxes": true
            }
        }
    }
 }

However, I don't believe using options is ideal. Most importantly, the submitted value dict using options is a list:

"impact": [
    "Impact Three"
]

rather than something that (i) shows boolean for all checkboxes (incl. defaults), and (ii) allows me to provide field names, e.g.:

"impact": {
    "impactOne": true,
    "impactTwo": false,
    "impactThree": false,
}

Hope this makes sense.

[radekmie]

Yes, it does make sense. In this case, I can suggest either making a custom component for it (just to make the data format "right") or transform the result array manually during submit (true if it's on the list, false otherwise). You can define filed names using value in the options.

[delyanr]

@radekmie I'm trying to use the options to define the field names as you suggested; however, there is some weird issue where if the label is different from the value, then the checkbox loses the ability to check and un-check. You can literally test it with the code from my previous comment (just change the value somewhere) and use AntD. Is this a bug, or am I doing something wrong?

[radekmie]

Yes @delyanr, that's definitely a bug (a weird one). Please file a new issue for it.