defaultValues Partial / DeepPartial causes unsafe typings

[quicksnap]

Is your feature request related to a problem? Please describe.

Consider the following:

interface MyFieldValues {
  name: string;
}

const MyForm = () => {
  const { watch } = useForm<MyFieldValues>({ defaultValues: {} });

  const name = watch('name'); // const name: string;

  name.toUpperCase(); // TypeError! name is undefined
};

The type inference for useForm is very good, but forcing a partial opens it up to unnecessary runtime errors.

In situations where your form may not have values present, it should instead be typed appropriately:

interface MyFieldValues {
  name: string | undefined;
}

Describe the solution you'd like

A few approaches come to mind:

• Remove DeepPartial. This would be a breaking change and possibly upset developers that do not want strict typing.
• Expose an alias, useFormStrict with a strict type definition. It would use the same runtime code as useForm
• Extend the generics of useForm to be useForm<TFieldValues, TContext = any, TStrictValues = false>(...). The types could leverage TStrictValues to conditionally use DeepPartial.

Describe alternatives you've considered

The current workaround is to strictly define your default values upfront:

const MyForm = () => {
  const defaultValues: MyFieldValues = {}; // Error: Property 'name' is .. required in type 'MyFieldValues'
  const { watch } = useForm<MyFieldValues>({ defaultValues });
// ... snip ...

This has the "pit of failure" downside--if developers forget to do this, they may encounter runtime errors later.

Additional context

Happy to contribute changes here if we want to make an adjustment for current or future version.

[quicksnap]

Additionally, in a stricter mode, defaultValues may want to be required.

[bluebill1049]

100% buy-in on this, we are moving away deepPartial for defaultValues and reset API. This is likely to be part of the next major V8, which reset is already been implemented. #7433 The sad thing is currently V8 branch is blocked by TS 4.7 update with lazy path check. It's a bumper for sure, we may have to give up on the lazy field path. #5941 (comment) Are you happy to close this feature request and leave a note in the RFC? let's move forward with this strict type check for defaultValues in v8.

[quicksnap]

If it's slated for V8, then that's perfect for me! Great to know. I'll leave a note there now.

[bluebill1049]

yes, we are definitely going ahead of that, especially since the lazy field path may have to be reverted due to the ts 4.7 change.