Consider reverting "Make fields with const pre-fiiled and readonly"

[MarekBodingerBA]

Prerequisites

• I have searched the existing issues
• I understand that providing a SSCCE example is tremendously useful to the maintainers.
• I have read the documentation
• Ideally, I'm providing a sample JSFiddle, Codesandbox.io or preferably a shared playground link demonstrating the issue.

What theme are you using?

core

Version

5.22.0

Current Behavior

The recent implementation of prefilled, readonly fields for const values, introduced by #4326, has led to a regression impacting various use cases.

In my opinion, this change is a regression as it alters expected behaviors in forms where user interaction is required. There are legitimate scenarios where fields with const values should not be readonly, such as (see playground):

• confirmation fields where users must manually enter a specific text,
• agree to terms by interacting with a checkbox.

Attempting to override the prefilled value with default does not work as expected, further complicating form configuration. The implementation should not automatically control whether a field is readonly. Flexibility should be provided to developers to define this behavior based on the specific use case.

Expected Behavior

Developers should have the option to configure whether a const field is prefilled and readonly or requires user input.

Steps To Reproduce

1. Open the playground.

Environment

No response

Anything else?

No response

[heath-freenome]

@MarekBodingerBA According to the spec a const value for a field restricts that field to have one value (i.e. it can never be changed). Is the idea that const for optional fields should not prefill? Also, you could use the uiSchema to force the field to be readonly: false I believe. Did you want to add an experimental flag that doesn't prefill const values? Let's talk about this some more.

[nickgros]

If you can prefill your form data and configure your uiSchema, you could do something like this to get the behavior you're looking for.

But if that's not an option for you, we might need to look into new feature flags.

[heath-freenome]

Ah wait, we also made the field readonly if const was specified. Perhaps that is what you are asking to roll-back?

[MarekBodingerBA]

@heath-freenome While I understand the spec's requirements, there might be legitimate use cases, such as an "I Agree" checkbox that should ultimately be checked true but not initially. How would you handle such a case?

Regarding "readonly": What's the standard for this library? Are other data types automatically set to readonly based on the schema, or is this the only case? If it's the only case, it should be considered whether this behavior is wanted for others or if there are other instances and it's consistent with the library's expected behavior.

@nickgros We unfortunately cannot prefill our form data due to the highly dynamic nature of our forms. We actually use getDefaultFormState on the backend to prefill the data before page rendering.

I think there are three options:

• Revert this change (probably not desired by others)
• Create a custom flag that won't prefill defaults for constants
• Make it respect defaults ({const: true, default: false}), though I'm unsure if this complies with the spec

What are your thoughts?

Thanks for all your work on this.

[heath-freenome]

@MarekBodingerBA Here's what we are proposing to do:

1. We will remove the automatic readonly of a const. If you want that behavior, use the uiSchema
2. We will be adding the following new Experimental_DefaultFormStateBehavior flag to support what you need:

 /** Optional enumerated flag controlling how const values are merged into the form data as defaults when dealing with
   * undefined values, defaulting to `always`. The defaulting behavior for this flag will always be controlled by the
   * `emptyObjectField` flag value. For instance, if `populateRequiredDefaults` is set and the const value is not
   * required, it will not be set.
   * - `always`: A const value will always be merged into the form as a default. If there is are const values in a
   *        `oneOf` (for instance to create an enumeration with title different from the values), the first const value
   *        will be defaulted.
   * - `skipOneOf`: If const is in a `oneOf` it will NOT pick the first value as a default
   * - `never`: A const value will never be used as a default.
   *
   */
  constAsDefaults?: 'always' | 'skipOneOf' | 'never';

Thoughts?

[MarekBodingerBA]

@heath-freenome Perfect! Would it make sense to support {const: true, default: false} also, or is it something that doesn't really fit?

[heath-freenome]

That would break the spec since const indicates that it is the only value a field can have