Basic support for 'nullable' types

[wms]

Reasons for making this change

Modifies the implementation of getSchemaType so that when a property has a type of [<any>, 'null'], then <any> will be passed. This allows the library to render and validate the field correctly. For the sake of simplicity, this change does not attempt any further assumptions, coercions or transformations.

References #465

Checklist

• I'm updating documentation
  • I've checked the rendering of the Markdown text I've added
• I'm adding or updating code
  • I've added and/or updated tests
  • I've updated docs if needed
  • I've run npm run cs-format on my branch to conform my code to prettier coding style
• I'm adding a new feature
  • I've updated the playground with an example use of the feature

[wms]

I wanted to land this PR in draft status before the end of the week in the hope that it'll get some eyes over the weekend. If this feature is desirable to the project maintainers, I'll add some tests and a Playground example when I return on Monday.

[wms]

@epicfaace Forgive the direct tag - this is ready for review, but I can't get the PR out of draft status. Hopefully the controls will appear for project maintainers.

[epicfaace]

Looks good! Thanks for the PR. One question: how does the code actually know to put null as the value when you leave a field empty that has type: ["string", "null"] ? Is this coming from ajv?

Can you add a test in which it renders a form with a nullable field and checks to make sure that when the field is emptied, its value is null?

[wms]

@epicfaace This PR doesn't actually go that far; having looked the history of closed, unmerged PRs that attempted to implement UX changes or other additional handling of such nullable types, I intentionally decided against that. This allows end-users to handle such scenarios themselves, either through custom widget implementations or uiSchema adjustments.

To quote from the FAQ entry change:

However, the actual rendering and handling of the field is unchanged; you are free to handle this using an approach ('ui:defaultValue': null, for example) best-suited to your use case.

Should I expand on this in the FAQ and/or elsewhere to make this point more clear?

[epicfaace]

@warrenseymour oh I see, thanks for the explanation. Just one small typo then and I think we'll be good to go! Thanks again!

I do think it might be nice to have some default handling of nullable types, but that can be added in the future as this change already goes pretty far.

[wms]

@epicfaace I completely agree. I've already started looking at how a nullable type can be rendered/handled in other layers of the library (perhaps in some opt-in manner, or a strictly 'bring-your-own-template' fashion), but that's another PR!

[FriOne]

@epicfaace hi, could you bump this change into npm?

[epicfaace]

I don't have access, @glasserc does

[FriOne]

Thought this solves validation problem when you want 3 types of values - any, undefined and null, but it is for a widget only :(

[epicfaace]

@FriOne I don't think it's possible to set a value equal to undefined in json schema. Feel free to make another issue regarding this so we can discuss your use case further though.

[FriOne]

@epicfaace sorry, I meant that this change doesn't allow null in values. I can set string or undefined and validation will be passed but can't set null.

[epicfaace]

@FriOne it should allow null in values. I've just updated the playground to the latest version; can you make an example on the playground and share it with me?

[FriOne]

@epicfaace the problem is on my side, my bad :)