formData definition in types should support undefined as a valid value

[dagda1]

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 or a shared playground link demonstrating the issue.

What theme are you using?

core

Version

5.x

Current Behavior

In versions before 5.0.0-beta.*, if the<Form /> was given a schema like this:

{
  properties: {
    repository: {
      type: "object"
    }
  }
}

The form component would call getStateFromProps which would, in turn, call computeDefaults and return:

{
  repository: {}
}

This would allow getDefaultFormState to initialise the form correctly.

The code in computeDefaults in v5.0.0-beta.* has an isEmpty check, meaning non-empty objects will not get initialised correctly, and formData will be {}.

The knock-on effect of that is that this code in ObjectField will return undefined for the formData:

        return {
          content: (
            <SchemaField
              formData={get(formData, name)}  // undefined

Any ui:field will receive undefined for the initial formData

Expected Behavior

formData should at least initialise to an empty object.

Steps To Reproduce

I created a failing test here.

Environment

- OS:osx
- Node:16
- npm:8

Anything else?

No response

[heath-freenome]

@dagda1 Were you depending on that behavior? Many people had been complaining that this behavior was, in fact, a bug and so it was fixed in #3287. If we provided an opt-in flag that would let you choose to initialize top-level objects as an empty object would that help?

Also, there is also a big issue (#2980) that indicates our automatically saving defaulting values in the formData is an actual bug itself, and that we should not do so ever.

[benjdlambert]

@heath-freenome me and @dagda1 discussed this a little bit, and we're happy that the behaviour is fine. However we noticed that the types for FieldProps could maybe do with updating? Just wanted to bring this to your attention before you cut a v5 release as I think it would be a breaking change. Seen as it now uses get and doesn't default, should formData this be optional?

interface FieldProps<T = any, S extends StrictRJSFSchema = RJSFSchema, F extends FormContextType = any> extends GenericObjectType, Pick<React.HTMLAttributes<HTMLElement>, Exclude<keyof React.HTMLAttributes<HTMLElement>, "onBlur" | "onFocus" | "onChange">> {
    /** The data for this field */
    formData: T;

[heath-freenome]

Thoughts @nickgros @epicfaace ?

[heath-freenome]

@heath-freenome me and @dagda1 discussed this a little bit, and we're happy that the behaviour is fine. However we noticed that the types for FieldProps could maybe do with updating? Just wanted to bring this to your attention before you cut a v5 release as I think it would be a breaking change. Seen as it now uses get and doesn't default, should formData this be optional?

interface FieldProps<T = any, S extends StrictRJSFSchema = RJSFSchema, F extends FormContextType = any> extends GenericObjectType, Pick<React.HTMLAttributes<HTMLElement>, Exclude<keyof React.HTMLAttributes<HTMLElement>, "onBlur" | "onFocus" | "onChange">> {
    /** The data for this field */
    formData: T;

Good catch. I will be pushing a PR against this issue to fix formData to support undefined everywhere

[dagda1]

Good catch. I will be pushing a PR against this issue to fix formData to support undefined everywhere

Great! Thank you