Unwanted default value for object field (regression introduced in 5.22.0)

[AlimovSV]

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

Current Behavior

If a schema contains an object field with subschema oneOf: { const: 123 } and emptyObjectFields <> 'skipDefaults', then the default value is applied as the first value from the oneOf subschema.

Expected Behavior

Object fields should not be populated if default value is not specified in the schema

Steps To Reproduce

Open playground: you will see a simple schema with one property WITHOUT default in the schema, but the RJSF set the default value as a first value from oneOf subschema. You can see this by trying to edit the form data (just try renaming prop -> prop2 and prop: 123 will be added automatically).

Environment

- OS:
- Node:
- npm:

Anything else?

No response

[heath-freenome]

@AlimovSV I'm not totally convinced it is a regression, but rather the result of fixing const so that it behaves like default in terms of populating default data (a very OLD bug). If you were to switch your const to be an enum with a default then you would get the same behavior.

You can also not make the const be required. If you need it to be a required field then you can simply set the experimental_defaultFormStateBehavior.emptyObjectFields' on Formto beskipDefaults`.

If that isn't acceptable, then let's discuss more.

This is probably not the first time that people rely on a bug as if it was a feature. And then when the bug get fixed suddenly there is a "regression".

[AlimovSV]

@heath-freenome Thank you for response. I think this is still a bug because:

1. form doesn't have a default value
2. the schema transforms into the select box (so the user has several options to choose from) but with a predefined first option

So the case where I want to force the user to make an initial choice is not possible. RJSF makes its choice. skipDefaults is not a good variant because it removes all defaults even for fields with default: x in the schema. I think that skipEmptyDefaults would be helpful, but it doesn't work for oneOf case too.

If you were to switch your const to be an enum with a default.

Yes, and this behavior is correct, because I have "default: 1" in the schema. But in my example the schema does not have a default. I agree that if the schema is const: 123 only (without oneOf choice), it is correct, because the user has no possibility to select something else, but when the schema contains a choice (oneOf or enum) and does not have a default - the automatic selection of the first possible value is not so good (why not the last or other one?). If I want the default for this case I must specify it in the schema.

[heath-freenome]

Hmmm, so maybe we add a new experimental_defaultFormStateBehavior flag to disable automatic const assignment as a default?

[AlimovSV]

as a variant - may be. but I still think that the schema

{
  "type": "object",
  "required": [
    "prop"
  ],
  "properties": {
    "prop": {
      "const": 1
    }
  }
}

should have automatic const assignment, but this schema should not have it:

{
  "type": "object",
  "required": [
    "prop"
  ],
  "properties": {
    "prop": {
      "type": "string",
      "oneOf": [
        {
          "const": "1",
          "title": "One"
        },
        {
          "const": "2",
          "title": "Two"
        },
        {
          "const": "3",
          "title": "Three"
        }
      ]
    }
  }
}

just because we are not 100% sure what value should be assigned to the data ("1", "2" or "3").

[nickgros]

@AlimovSV what do you think of the proposal in this comment? Would the skipOneOf flag solve this issue for you?

[AlimovSV]

@nickgros Yes, thank you, I like it!

[AlimovSV]

@nickgros Yet another issue I observed: when const: has $data specs (using AJV $data: true configuration - unfortunately the playground doesn't allow to configure AJV and validation will not work properly but this is not important), the constAsDefault logic populates it in naive manner - just copy the value. And the email confirmation becomes [object Object] in the UI and { "$data": "1/email" } in the form data. Of course when I make constAsDefault="never" this behavior is gone, but I think it would be worth to handle such a case in some alternative manner. Thoughts?