better support for const

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

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://rjsf-team.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

[epicfaace]

I think the two you enumerated are the main things that would need to be changed.

Some things to consider:

• What if a user enters {default: "value1", const: "value2"}? I'm thinking that the default value should be set to value1, not value2.
• readonly vs disabled: I'm thinking it makes most sense to use readonly, not disabled? Looking at this explanation, I'm not sure if rjsf is correctly handling the behavior of disabled though because disabled elements in HTML do not send their values upon submit (but that's probably a whole other issue)
• Right now, doing {enum: ["value1"]} and {const: "value1"} are basically interchangeable in the schema. That brings the question -- do we want the widget for const to be a readonly field, or instead a dropdown with just one value in it?

[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.

[epicfaace]

I agree -- makes sense, feel free to implement this in a PR.

[Saulzi]

@epicfaace please see my bigger commit as I added pre-populating based form with const value / readonly. and if / then / else

from looking at the spec

7.6. Assertions
JSON Schema can be used to assert constraints on a JSON document, which either passes or fails the assertions. This approach can be used to validate conformance with the constraints, or document what is needed to satisfy them.

JSON Schema implementations produce a single boolean result when evaluating an instance against schema assertions.

https://json-schema.org/draft/2019-09/json-schema-validation.html#rfc.section.6.1.3

6.1.3. const
The value of this keyword MAY be of any type, including null.

Use of this keyword is functionally equivalent to an "enum" with a single value.

An instance validates successfully against this keyword if its value is equal to the value of the keyword.

one thing to bear in mind thinking about it and the if / then / else if stuff essentually if a field is not required then it can potentually be undefined or the const value, how does ajv handle this when validating?

[ranihorev]

Hey! I was trying to review the different issues and PR but couldn't figure out if anyone is working on this at the moment. I'm happy to contribute if I can.

[chrisui]

Is it possible to revive this somehow? Happy to help.

Using something like typebox or in general just making high use of discriminated-unions in TS will lead you to a PITA here as the current behaviour for const fields isn't great.

[heath-freenome]

@chrisui With the v5 beta just being released this is the perfect time to help.

[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!

[multimeric]

So one use case where const should affect the UI and currently doesn't is when you want the user to select between multiple consts:

{
  "oneOf": [
    {
      "const": "foo"
    },
    {
      "const": "bar"
    }
  ]
}

This displays nothing at all, which is an issue because the user needs to be asked to choose between these two options. Of course in this case an enum could be used, but actually it's a better practise to use const and title to get named enums according to the spec: json-schema-org/json-schema-spec#57.

[heath-freenome]

@multimeric I agree we need to fix this. Are you willing to provide a PR for it? If so, I could walk you through the steps of fixing this.