react-hook-form: ESlint TypeScript error `unbound-method`

Describe the bug Deconstructing register from useForm triggers @typescript-eslint error unbound-method

To Reproduce Use ESlint with a rule mentioned above.

Codesandbox link (Required) CodeSandbox does not support ESlint (https://github.com/codesandbox/codesandbox-client/issues/1933)

Expected behavior register is not a method that depends on this context, so should not trigger a warning. handleSubmit doesn’t.

Screenshots Screenshot from 2020-09-11 15-40-37

Desktop (please complete the following information):

  • OS: btw, I use Arch (not really, Manjaro)
  • Browser Vivaldi
  • Version up to date 😛

Additional context Similar problem with Formik: https://github.com/formium/formik/issues/2589

PR welcome? I can contribute

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 14
  • Comments: 30 (22 by maintainers)

Commits related to this issue

Most upvoted comments

Thank YOU. v7 looks great! Can’t wait to use it in production 😊

Going to try to resolve this at v7.

I am going to close this issue, this will be fixed in v7 (release in 2 weeks) 👍

@bluebill1049 even after v7 release the error is present.

I just updated & uploaded repo with repoduction in CI. PR with build here: https://github.com/Tymek/rfh-eslint/pull/1, with version 7-alpha.0

All checks have passed!!! ✔️✔️✔️✔️✔️✔️✔️✔️✔️✔️

(v6 failing: https://github.com/Tymek/rfh-eslint/runs/1765302666)

How I understand current situation with this refactor: Problem is, previously type-checking was terminated whenever we where using Control. Control was terminating what could/couldn’t be passed and was defaulting/casting it to Record<string, any> every time. This way many things where compatible, for example: strict useForm<FValues>() with loose useFormContext()

With the changes, strict and specific Control<FormValues> was not compatible with generic TControl or Control<any>

First, I will try to find a way to make something like Control<{ x: string, y: string }> match when we need Control<{ x: string }> in useWatch and other similar cases.

Second, how rigid should it be about passing strict-typed Control into those functions?

  const FValues = {
    x: string,
    y: string,
  }

  const { control } = useForm<FValues>() // strict
  const A = useWatch<FValues>({ name: 'x', control }) // will work
  const B = useWatch({ name: 'x', control }) // "loose"? should probably be allowed

Maybe in this case allowed values for name can be inferred from control? I just hope reverting to weird 💫 FieldValuesFromControl is not necessary.

I could reproduce reported error #3002 with app/src/useWatch.tsx test. Thx @maxsbelt, I will check what’s going on with watch signature.

Now I will continue toying with this issue on a side 😉. Extensive testing will be needed.

@Tymek I created a sandbox with a simple reproducible example: https://codesandbox.io/s/fervent-haibt-t5zmi?file=/src/useMyForm.ts

example

I got different results with:

export type Control<TFieldValues extends FieldValues = FieldValues> = Pick<
  UseFormMethods<TFieldValues>,
  'register' | 'unregister' // ...
> & {

vs

export type Control<TFieldValues extends FieldValues = FieldValues> = {
  register: UseFormMethods<TFieldValues>['register'];
  unregister: UseFormMethods<TFieldValues>['unregister'];
  // ...

wut. 😦

I think I had some tests or branch with modified ESlint config. I’ll check this in a day or two and let you know how

I guess you can mute the error using @ts-expect-error, and it will also notify you when the problem is resolved (aka there is no error anymore)

thanks @Pirastrino 🙏 pretty sure @Tymek already tried that.