oneOf + const is handled differently when nested in a property vs as a root object property

[PC-Gonzales]

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?

mantine

Version

6.3.1

Current Behavior

It's possible there's something I don't understand about JSON Schema or RJSF here, but this seems like a bug to me.

This is with the following feature flag:

experimental_defaultFormStateBehavior={{
  constAsDefaults: 'always',
}}

The first schema will have the behavior of enforcing food equals "fish" if animal equals "Cat". Even if the user uses the dropdown to select a different value, it forces it back to the const value.
The second schema is essentially the same schema, except nested inside a property nested. The above behavior is no longer observed.

Validation is not broken, but the UX behavior changes.

Working playground with the schema below:

{
  "type": "object",
  "properties": {
    "animal": {
      "enum": [
        "Cat",
        "Fish"
      ]
    },
    "food": {
      "type": "string",
      "enum": [
        "meat",
        "grass",
        "fish"
      ]
    }
  },
  "allOf": [
    {
      "if": {
        "properties": {
          "animal": {
            "const": "Cat"
          }
        }
      },
      "then": {
        "properties": {
          "food": {
            "const": "fish"
          }
        },
        "required": [
          "food"
        ]
      }
    },
    {
      "required": [
        "animal"
      ]
    }
  ]
}

Bugged playground with the schema below:

{
  "type": "object",
  "properties": {
    "nested": {
      "type": "object",
      "properties": {
        "animal": {
          "enum": [
            "Cat",
            "Fish"
          ]
        },
        "food": {
          "type": "string",
          "enum": [
            "meat",
            "grass",
            "fish"
          ]
        },
        "allOf": [
          {
            "if": {
              "properties": {
                "animal": {
                  "const": "Cat"
                }
              }
            },
            "then": {
              "properties": {
                "food": {
                  "const": "fish"
                }
              },
              "required": [
                "food"
              ]
            }
          },
          {
            "required": [
              "animal"
            ]
          }
        ]
      }
    }
  }
}

Expected Behavior

Consistent UX behavior whether the allOf is the root object or a nested object property.

Steps To Reproduce

Observable in the plaground via the two links above

Environment

- OS: Windows 11
- Node: 22.13.1
- npm: 11.7.0

Anything else?

No response

[heath-freenome]

@PC-Gonzales Wow, this is an interesting bug. It may be due to the merge-all-of library we are using from @x0k OR it might be some weird nesting issue in our getDefaultFormState() that @abdalla-rko has done a fair bit of work improving. We'd love someone to dig into this and provide a PR with a fix

[x0k]

1. The keyword allOf should be used at the object level, not in properties
2. Most likely, you want to use the following condition:

{
  "properties": {
    "animal": {
      "const": "Cat"
    }
  },
  "required": [
    "animal"
  ]
}

3. To calculate the default value in a nested case, you must use allOf: "populateDefaults"

4. Why does the value remain fish in the first case, but can be changed in the second?

   In the first case, the value is overwritten with the default value in this branch (to overwrite undefined, you must use mergeDefaultsIntoFormData: "useDefaultIfFormDataUndefined").

   In the second case, the default value for the nested key is overwritten by the value of the form in this branch.

[heath-freenome]

@x0k Are we missing a setting in how we are using your library in our retrieveSchema.ts file?

[x0k]

No, I mean this is incorrect:

{
  properties: {
    allOf: [...],
  },
}

it should be:

{
  properties: {...},
  allOf: [...],
}

[heath-freenome]

@x0k So the schema in this playground is correct? And it still exhibits the issue :(

[x0k]

An invalid schema is just one of the four issues I outlined in this comment.

[heath-freenome]

@PC-Gonzales So this playground seems to be working. Thanks @x0k

[PC-Gonzales]

Oops, my mistake on the allOf being in properties. I think I copied the wrong thing—I had so many notepads open while I was messing with the schema trying to figure out why things weren't working as expected.

@x0k @heath-freenome That example provided doesn't fix what I'm seeing. Maybe I poorly explained what I'm experiencing, here is a video:

rjsf_example.mp4

[heath-freenome]

@abdalla-rko Since you are well versed in the defaults population logic, can you look into this issue? Thanks.