Add support for type: with multiple options

[5c0r]

Prerequisites

• I have read the documentation.

Description

I am using Json.NET Schema to return a Json Schema with this type of properties

        "AddressList": {
          "type": [
            "array", 
            "null" 
          ],
          "items": {
            "type": [
              "string"
            ]
          }
        },

According to Json Schema specification, type array which has null will also represent Optional input.
If change to

 "type: " [ "string"]

or

"type:" : "string"

Everything would work fine

Expected behavior

• I expect this to display an input field which more record can be added

Actual behavior

• Unsupported field schema { "type": [ "array", "null" ], "items": { "type": [ "string" ] } }.

Version

I am running this on Playground Page directly

[mplis-jetsetter]

I don't think this library supports type being an array. Is there a reason simply setting "type": "array" isn't sufficient for you? Maybe there's another way to do what you're trying to do.

[5c0r]

I just think that this library should also conform JsonSchema v4 specification also :D . Since I will have to stuck using Json.NET Schema to generate Schema for creating forms. I can try modify the source code so "type" can be used as an array.
I can send a Pull Request also if you think this is worth something :D

[n1k0]

TBH the hard part is not supporting the null schema type programmatically but rather exposing a decent UI/UX for dealing with it. That would mean adding a control for stating if a given field should be set to null or something else.

[mplis-jetsetter]

@nmt1994 this isn't just a JsonSchema validator though, it's a UI generator too. Not every aspect of the JsonSchema spec translates nicely to a UI element. Like @n1k0 said, how would you design a UI to show that an input can either be an array or null? And why would that be useful? And what about the general case where type is some arbitrary array of types? What does the UI look like for type: ['number', 'string']? Or type: ['array', 'object', 'string']?

[5c0r]

@n1k0 : Thanks a lot for your reply . I just re-read through the JSON Schema validation and it seems that it doesn't provide much examples that would cover cases such as @mplis-jetsetter mentioned above.
Initially my thought was just [ "string" ,"null"] would be : A text field which can be left optional. Seems that I was wrong in the beginning.

Regarding UI/UX related , I don't have any good idea for now . Maybe validating the type before generate any UI ( i.e : type cannot have string & array simultaneously )

[glasserc]

Is this addressed now that we've merged #442? Now, "optional" strings are dropped from formData. If not, can we maybe rephrase this issue a little bit? Is the problem that we don't support type: [...]? Is the problem that we don't support null for any types?

[5c0r]

@glasserc : Hello :)
Thanks for picking this issue .The problem was type : [] is not supported . However, I created another server-side implementation to conform with the library already.
And IMHO, "null" in type may be was referencing nullable ( not required ? ) , but that was already define in "required" property . Then I don't think support for "null" type is needed...(even if it is drafted in JsonSchema specs ) , that would make validation more complex ...

I will take a look if this problem is fixed with your mentioned pull request :)

[mfulton26]

FYI: A similar library to this one solves this problem by providing the user with a "type" select next to the field label (demo here). It also supports not defining "type" which then allows the user to enter arbitrary JSON using it's UI.

Personally I would love to see a similar feature in react-jsonschema-form.

[handrews]

According to Json Schema specification, type array which has null will also represent Optional input.

This is not actually correct. A type array which has null in it means that the null JSON literal is allowed. An optional field is a field that can be omitted entirely, which is controlled by the required keyword. Present with null and omitted are different cases in JSON. Some strongly statically typed language implementations struggle with this distinction, as it requires dynamically defining fields.

[handrews]

I just think that this library should also conform JsonSchema v4 specification also

If there's any measure of conformance, I strongly recommend measuring against draft-06 or later, not draft-04. Draft-06 is the first modern draft (since the spec process re-started), and we are de-emphasizing tools that only support draft-04 on the json-schema.org implementation list. Many draft-04-only tools are moribund, and we are particularly de-emphasizing those (obviously this project is not moribund).

Draft compliance is a little different for generators, since as noted not all keywords make sense anyway. But if the keywords you support work in the way that draft-06 or later require (e.g. exclusiveMinimum and exclusiveMaximum are numbers, not booleans, in draft-06 and later), then you'd be considered draft-06-compatible.