issue: Error message have wrong type when using useFormContext

[alveshelio]

Version Number

7.33.1

Codesandbox/Expo snack

https://codesandbox.io/s/react-hook-form-chakra-ui-3nbwup

Steps to reproduce

I have react-hook-form with Chakra-ui and after updating to the latest version of react-hook-form (7.33.1) and @types/react (18.0.15) and @types/react-dom (18.0.6)

When creating a component and using useFormContext(), when trying to display the error message in
Chakra-ui <FormErrorMessage> component I'm getting this error:

Type 'Merge<FieldError, FieldErrorsImpl<DeepRequired>> | undefined' is not assignable to type 'ReactNode'.
Type 'Merge<FieldError, FieldErrorsImpl<DeepRequired>>' is not assignable to type 'ReactNode'.
Type 'Merge<FieldError, FieldErrorsImpl<DeepRequired>>' is not assignable to type 'string'.

This only happens when we use useFormContext(). As you can see in the provided codesandbox, when registering an input with {...register('lastName')} I don't have this issue.

Expected behaviour

Expected errors to not throws type errors.

What browsers are you seeing the problem on?

No response

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[bluebill1049]

hey @alveshelio

useFormContextz() generic is required not optional if you want to have the correct type of support, if you don't want to have type check then you should provide any (getting that patched)

ref: https://github.com/react-hook-form/react-hook-form/blob/master/src/useFormContext.tsx#L38

- useFormContext() 
+ useFormContext<FormValues>() // or useFormContext<any>()

[bluebill1049]

This will get patched in the next release, however, without a generic provided, we really can't do any type check for your form. Hope the above makes sense as well.

[craigmcc]

If you show me exactly where I should provide a generic, I will take a look. But the fact remains that in 2.32.0 everything works fine, and in 2.33.1 everything is broken. If that's not a problem in your eyes, then I will definitely need to look elsewhere for a React form library.

…

On Fri, Jul 8, 2022 at 4:34 PM Bill ***@***.***> wrote: This will get patched in the next release, however, without a generic provided, we really can't do any type check for your form. Hope the above makes sense as well. — Reply to this email directly, view it on GitHub <#8653 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA7ZLV4I5LOJ5SM22W5Z73VTC3HRANCNFSM53CJQEFA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[bluebill1049]

@craigmcc please look elsewhere if this block you.

[alveshelio]

Hi @bluebill1049,

Thank you for getting back. I've tried with useFormContext<any>() and it doesn't help much, the error is still present. The only way I'm able to keep TypeScript happy was to do (errors["firstName"]?.message as unknown as string). I hope this is only a temporary fix.

Again, I appreciate your help in this.

[bluebill1049]

hey, @alveshelio Would it be possible to provide a type definition for your form for the useFormContext?

However, as you can see there is no type check for errors, it's literally any.

The only way I'm able to keep TypeScript happy was to do (errors["firstName"]?.message as unknown as string)

Not ideal, but doing this is probably better String(message)

By looking at the issue a bit deeper, looks like without type definition then casting to string is required, this is simply due to without generic being provided for the type check.

[alveshelio]

Hey @bluebill1049,

I really can't thank you enough for being to quick and so helpful.

I've made a donation a couple of weeks ago and I know that it is not near enough for all the great work you put into react-hook-form but it's a small gesture to encourage people like you who put so much of your time into open source and I think some times we forget how much these open source projects helps us. Once again, a big thank you.

Regarding providing a type definition, in the codesandbox I've provided, if I pass FormValues to useFormContext<FormValues>() then it solves the problem. I'm just wondering how I can make it work when it comes to a component with a generic type. If I do something like this

const ControlInput = <T extends FieldValues>() => {
  const {
    register,
    formState: { errors }
  } = useFormContext<T>();

  return (
    <FormControl id="firstName" isInvalid={!!errors["firstName"]}>
      <Input {...register("firstName")} placeholder="First Name" />
      <FormErrorMessage>{errors["firstName"]?.message}</FormErrorMessage>
    </FormControl>
  );
};

Then I get this:

[bluebill1049]

I think it's probably not possible to infer the type through a generic by extending FieldValues wihotut providing a type definition for your form because it simply couldn't infer what's been passed at the component level. Basically useFormContext will always require to be provided with a generic for your form, I will update the changelog to info this potential breaking change for those who didn't provide a generic, the latest minor change we did, successfully eliminated NestedValue type and this is a great step moving forward to simply the type definition for

• developers without having to worry about Nested data input
• and in some extent improve the TS improvement
• unlocks the next big feature rules for useFieldArray (useFieldArray rules props (#8102) #8562)

At the moment, I do feel the pain that may cause to users who didn't provide a generic for useFormContext, unfortunately, without the type provided we can't correctly support the type check, and you will have to use String(message) to guarantee the type check for the error message.

[bluebill1049]

I have reverted the previous two commits made for this issue as they are not really addressing this issue.

[alveshelio]

Thank you, I'm fine for the time being to use String(message), I can simple point to this issue and make sure to review my code base and pass a generic whenever possible to useFormContext().

[bluebill1049]

Thanks for understanding @alveshelio I have updated the changelog to point this out, I am pretty excited for the next feature for useFieldArray rules prop, we can finally validate field array by the build-in validator. Make sure you cast your API preference in the poll if you are going to use it. #8562 Also thank you very much for the donation (forgot to mention that)