About form behavior when empty input is performed

[yap-house]

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?

mui

Version

">=6.5.3"

Current Behavior

For fields with default set in JSONSchema, the input cannot be empty unless ui:emptyValue is specified in UISchema.

See: Example1

Also, if you specify ui:emptyValue in UISchema, it will not be able to recognize the empty value, so required will not work in form validation, or if you specify null, the validation result will be displayed as a type error instead of a required error.

See: Example2

In addition, up to v6.5.2, an empty field in the form data as an argument of the onChange event was undefined with a key, but from v6.5.3 the form data is passed without the field itself.Currently, in this development environment, there are many problems related to state management due to the RJSF version update.

JSON Schema:

{
  "type": "object",
  "properties": {
    "someStrings": { "type": "string" },
    "someNumbers": { "type": "number" }
  }
}

v6.5.2:

const [formData, setFormData] = useState({
  someStrings: undefined,
  someNumber: undefined,
});

<Form
  schema={schema}
  formData={formData}
  onChange={(e) => {
    console.log(e.formData);
    /*
     * // If the input value is empty
     * {
     *   someString: undefined,
     *   someNumber: undefined
     * }
     */
  }}
/>;

>=v6.5.3:

const [formData, setFormData] = useState({
  someStrings: undefined,
  someNumber: undefined,
});

<Form
  schema={schema}
  formData={formData}
  onChange={(e) => {
    console.log(e.formData);
    /*
     * // If the input value is empty
     * {
     * }
     */
  }}
/>;

Expected Behavior

As with v6.5.2, I think the following behavior is natural.

• default takes effect only when the form is first displayed and allows empty input
• The formData of onChange stores undefined with a key so that if the field is empty, it will be known that the field is unfilled.

Steps To Reproduce

Example1

1. See: Example1
2. Empty the value of each input item using the BackSpace key etc.
3. You can confirm that the input field cannot be empty

Example2

1. Example2
2. Empty all input fields
3. You can see that the required field allows empty and the optional field results in a type error.

Environment

- OS: Windows, macOS
- Node: v24.15.0
- npm: v11.12.1

Anything else?

This symptom appears to be an unintended side effect of the fix for #4518 introduced in v6.5.3.

Releases/v6.5.3

Fixed processPendingChange leaving optional object keys as undefined after clearing text inputs (invalid for AJV type: "string"), by unsetting keys for resolved non-oneOf/anyOf leaves while preserving explicit undefined for oneOf/anyOf branches, fixing #4518

Form.tsx

The fix for #4518 was valid — leaving undefined values in formData for type: "string" fields caused AJV type errors. However, this fix introduced the following tradeoffs:

1. Fields with default can no longer be cleared. When the user empties an input, the default value is reapplied because the key is removed from formData and the schema default takes effect again.
2. onChange no longer reports empty fields. Previously, formData included { someString: undefined } for empty fields, allowing callers to distinguish "field is present but empty" from "field was never set". Now the key is omitted entirely ({}), which breaks state management code that relies on key presence.

Would it be possible to address both constraints — for example, by using undefined with keys preserved in onChange while only stripping them at validation time, or by providing a way to opt in to the old behavior?

Thank you for taking a look at this.

[Ingole712521]

Can i Work on this issue ?

[yap-house]

@heath-freenome @nickgros @Ingole712521

Thank you for the fix! I've confirmed that fields can now be cleared without specifying ui:emptyValue. I appreciate everyone's efforts on this.

@heath-freenome @nickgros

However, I've discovered a regression introduced by this fix.

Bug reproduction video (18 sec):

2026-06-28.22.15.11.mov

Steps to reproduce

1. Pull the latest main
2. Build and run pnpm start in packages/playground
3. Open the Sample link
4. Clear the "SomeStrings" field
5. Clear the "SomeNumbers" field → the "SomeStrings" field is repopulated with its default value
6. Clear the "SomeStrings" field → the "SomeNumbers" field is repopulated with its default value

Root cause

The issue appears to be in the following section of processPendingChange, which re-merges default values into previously-cleared fields:

react-jsonschema-form/packages/core/src/components/Form.tsx

Lines 1004 to 1013 in 7bda079

	const newState = this.getStateFromProps(
	this.props,
	inputForDefaults,
	undefined,
	undefined,
	undefined,
	true,
	shouldSanitize,
	);
	formData = newState.formData;

Changing _unset(formData, path) to _set(formData, path, undefined) in processPendingChange — preserving the key with an undefined value rather than removing it entirely — appears to resolve the issue.

If this fix has no adverse effects on other functionality, it would be great to have it incorporated.

Note: Since this regression has not yet been released, it can only be reproduced by pulling main and testing locally.

Should I open a new issue to track this regression, or is it appropriate to continue here?

I would also like to contribute a fix via pull request. Could you point me to the preferred workflow? Should I fork the repository and open a PR from my fork? Are there any branch naming conventions I should follow?

Thank you for your time.

[nickgros]

@yap-house Nice catch! Yes, if you want to contribute the fix you would create a branch on your forked repository and open the PR against this one. We don't have any strict convention for branch name.

Just ensure you add a test for the new regression, and ensure the pre commit is set up to format and lint, and you should be good to go. There's a checklist that shows up in GitHub when you open the PR that you can walk through.