[react-form] there is no way to clear a form value if it has a default value.

[a-eid]

Describe the bug

useForm({
  defaultValues: {
    status: params.get('status') // assume this is active for example 
  }
})

      <form.Field name="status" asyncAlways>
        {(field) => (
        .... 
        field.setValue(undefined) // doesn't work. it resets status to active.
        form.setFieldValue("status", undefined) // doesn't work. it resets status to active.
        field.setValue(undefined) // doesn't work. it resets status to active.
        )}
      </form.Field> 

they all default to the default value

Your minimal, reproducible example

TODO

Steps to reproduce

N/A

Expected behavior

I would expect that setValue / handleChange would accept undefiend and it wouldn't be overridden by the default value.

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

• OS: Macos
• version: ^1.0.5

TanStack Form adapter

None

TanStack Form version

^1.0.5

TypeScript version

No response

Additional context

No response

[vitassuper]

Consider to use null instead of undefined.

[LastGunslinger]

@vitassuper I'm currently using v1.1.0 and also having this problem. In this case I do think that is is a bug, or if not, then it should probably be expressly spelled out in the docs that this is not supported. For example, I if I have a type like this:

type Exmaple = {
    first: string | undefined
    last: string | undefined
}

Where undefined is a valid value for one of the fields, and I set up a form with useForm:

const form = useForm({
    defaultValues: { first: 'John', last: 'Smith' } as Example,
   // useForm options
})

then I would think that undefined is a valid value for either field. But in the form itself, if I do something like this:

<form.Field name='first'>
    <CustomInput
        // Line below has unexpected behavior if value is undefined, and does not raise a type error because undefined IS a valid value
        onChange(value => field.handleChange(value))
    />
</form.Field>
field.handleChange(undefined)

Instead of setting the value of that field to undefined, it will instead be reverted to 'John'. This seems like a bug to me, especially since it is typed correctly, and other form libraries that I've used in the past have not had issues with this. While agree that using null instead of undefined is probably a better choice, this conflicts with a lot of form validation that my company uses with Zod's partial() property, which is usually where the undefined values are coming from. Unfortunately Zod does not have a good way currently of making all of an object's fields null-ish (null or undefined) , so for now the partial function is the best that we can do.

[a-eid]

Consider to use null instead of undefined.

unfortunately neither null nor undefined work.

[LastGunslinger]

In my case, using null does work, but it required a refactor of my validation schemas to get there.

[a-eid]

@LastGunslinger what changes did you make, my form element is optional and should acception undefined values. ?

[LastGunslinger]

@a-eid I ended up changing the type of the defaultValues property in the useForm hook, from something like this:

type User {
    firstName?: string | undefined
    lastName?: string | undefined
}

to something like this:

type User {
    firstName?: string | null | undefined
    lastName?: string | null | undefined
}

Then I just made sure that all of my field.handleChange calls used null instead of undefined when called:

<CustomInput
    // {...otherProps}
    onChange={(value: string | null | undefined) => field.handleChange(value ?? null)}
/>

After making these changes I don't have the issue anymore, but it did require a substantial change for my project. My actual defaultValues type is not so simple, it's defined as Zod schema based on a larger type, but the idea for fixing it is the same.

[jashworth]

This seems like a bug to me, especially since it is typed correctly, and other form libraries that I've used in the past have not had issues with this.

field.handleChanged(undefined);
field.setValue(undefined);
form.setFieldValue("AField", undefined);
form.setFieldValue("AFieldContainingAnOptionalProp", { }); // prop is set to default value, NOT omitted

The fact that all these can result in the field being set to something other than undefined seems counterintuitive and likely to lead to some ugly workarounds. (I outline one here.)

Is the rationale behind this behaviour explained anywhere?