better support for const

Prerequisites

• I have read the documentation;
• In the case of a bug report, I understand that providing a SSCCE example is tremendously useful to the maintainers.
• Ideally, I’m providing a sample JSFiddle or a shared playground link demonstrating the issue.

Description

Currently, const is only used to validate the form data, but there is no UX to enforce it. This is a proposal to add more support of const.

Steps to Reproduce

https://mozilla-services.github.io/react-jsonschema-form/#eyJmb3JtRGF0YSI6e30sInNjaGVtYSI6eyJ0aXRsZSI6IkEgcmVnaXN0cmF0aW9uIGZvcm0iLCJkZXNjcmlwdGlvbiI6IkEgc2ltcGxlIGZvcm0gZXhhbXBsZS4iLCJ0eXBlIjoib2JqZWN0IiwicHJvcGVydGllcyI6eyJmaXJzdE5hbWUiOnsidHlwZSI6InN0cmluZyIsInRpdGxlIjoiRmlyc3QgbmFtZSIsImNvbnN0IjoiQ2h1Y2sifX19LCJ1aVNjaGVtYSI6e319

Expected behavior

const should be respected in various areas:

• default form values
• readonly / disabled form fields
• any other places?

Actual behavior

Only form validation respects const. It does not get applied as a default form state and there is no UI indiciation that a field cannot be changed from a certain value.

Version

1.3.0

[rap1ds]

Hi, we have forms where we use const values. We don’t need/want to show the input field for those. Thus, we use ui:widget: "hidden". There are a couple of situations where the library behaves a bit differently from what we’d expect:

1. Const + hidden widget

A form with const + hidden widget is always invalid

Playground example

What I’d expect: const value is automatically picked as the value of the hidden field

Actual: const value is not automatically picked, making the form always invalid

The workaround for this is to use default, but it also fails when the form data already exists, see the example below.

2. Const + default + hidden widget

A form with const + default + hidden widget is always invalid if form data already contains data (e.g. data loaded from server) that doesn’t match const. Because the field is hidden, there’s no way in the UI to make the form valid.

Playground example

Expected: const value overrides the existing value in form data.

Actual: Old value is not overriden, no way to change and the form. Form is always invalid.

3. Const with complex data + hidden widget

We’d also want to use const with other data than primitives. But we don’t need/want to show anything in the UI, thus we tried to use the hidden widget. However, hidden widget doesn’t support complex data.

Playground example

Expected: const value would be added to form data

Actual: const value is not added to form data because hidden widget doesn’t support complex data

I hope these examples provide some context if you plan to work with this issue!

Thanks for the library, awesome work!

[a-b-r-o-w-n]

@epicfaace

IMO, the default should be set to the const because the form would be invalid if using an incorrect default field. A readonly field makes sense to me. I think in the case of the single enum field, I would expect the form to render a dropdown with 1 element even though a const might be the same thing. In my own usage, we sometimes populate the enum dynamically and it could only have 1 element, and is semantically different than a const. I would like for our users to know that there could be more options, but just not now.