Typescript error with form and handleSubmit

[SalahAdDin]

Hi guys,

I'm using this for handling my form states, together with Typescript, but now, I'm getting an error with type checking:
Promise-returning function provided to attribute where a void return was expected.

My code is this:

const { dispatch } = useContext(Context);

  const form = useForm<ICreateTaskForm>({
    defaultValues: { title: '', description: '' },
    resolver: yupResolver(schema),
  });
  const { control, handleSubmit, reset } = form;

  const onSubmit = handleSubmit(({ title, description }: ICreateTaskForm) => {
    dispatch({
      type: ActionTypes.createTask,
      payload: { id: nanoid(), title, description, status: 'ToDo' },
    });
    reset();
  });

return(<form onSubmit={onSubmit}>
        <TextInput name="title" control={control} label="Title" required />
        <TextInput
          name="description"
          control={control}
          label="Description"
          required
          multiline
          rows={5}
        />
        <Button type="submit" variant="contained" startIcon={<Add />} fullWidth>
          Add
        </Button>
      </form>)
      

I know handleSubmit returns a  Promise, but I don't know how to solve this problem.

Can anyone help me?

Thanks

[sergey-sivchenko]

Same issue for me coming from @typescript-eslint/eslint-plugin.

Another related case would be not spreading the registered field properties:

const field = register("field");
...
<input
  ref={field.ref}
  name={field.name}
  onBlur={field.onBlur} // Same error here as onBlur returns Promise<void | boolean>
  onChange={field.onChange} // Same error here as onChange returns Promise<void | boolean>
  type="text"
/>

[Moshyfawn]

Hey!

Please, take a look at this CSB and possibly tweak to match your use-case, where you get the error.

[sergey-sivchenko]

Hey!
Sorry for not providing the code example, but as far as I understand CodeSandbox does not support custom eslint config. So, you will not be able to see the errors mentioned above in CSB. However, I created the example based on your CSB, which produce same errors locally:

Summary of changes

1. Changed tsconfig.json to the default from CRA template typescript
2. Extended default CRA ESLint config with Typescript ESLint Linting with Type Information
3. Replaced spread from title field by direct props passing

[Moshyfawn]

Thx for the example! Will take a look

[sergey-sivchenko]

Here is the situation as I understand it according to the types:

• @typescript-eslint can provide lint rules with access to all of the type information that TypeScript knows about your codebase, which is fine
• its no-misused-promises rule forbids providing Promises to logical locations in places where the TypeScript compiler allows them but they are not handled properly, which is fine
• react's form accepts onSubmit?: FormEventHandler<T> | undefined;, which is essentially EventHandler and it is not async function, which is fine
• react's input accepts onChange?: ChangeEventHandler<T> | undefined;, which is essentially EventHandler and it is not async function, which is fine
• react-hook-form's handleSubmit creates a submit function, which is async function and returns Promise<void>, which is fine by itself
• react-hook-form's register creates ChangeHandler, which is async function and returns Promise<void | boolean>, which is fine by itself

Despite the fact everything might work as expected from the code point of view, combining together react's form and react-hook-form's submit function (as well as react's input and react-hook-form's ChangeHandler) we are getting a combination of regular and async functions, which leads to the situation when we have not properly handled Promises. As a result we have an error from @typescript-eslint.

Please, feel free to correct me if I'm wrong somewhere as I am neither an expert in Typescript nor in react-hook-form.

[egerpe-ats]

The documentation of @typescript-eslint suggests disable the rule only for that particular case. Maybe it's not a solution but it does the trick for me.

[SalahAdDin]

Of course we are using this trick, we report this here cause it should be a better solution.

[leapful]

@SalahAdDin , @sergey-sivchenko :

Since it's just a linting error from eslint rule, not typescript error, the last thing you can do is following its best practice to avoid potential issue, may be a promise handling wrapper like this:

function onPromise<T>(promise: (event: SyntheticEvent) => Promise<T>) {
  return (event: SyntheticEvent) => {
    if (promise) {
      promise(event).catch((error) => {
        console.log("Unexpected error", error);
      });
    }
  };
}

Demo: https://codesandbox.io/s/serene-grass-vehq90?file=/src/App.tsx

[SalahAdDin]

@SalahAdDin , @sergey-sivchenko :

Since it's just a linting error from eslint rule, not typescript error, the last thing you can do is following its best practice to avoid potential issue, may be a promise handling wrapper like this:

function onPromise<T>(promise: (event: SyntheticEvent) => Promise<T>) {
  return (event: SyntheticEvent) => {
    if (promise) {
      promise(event).catch((error) => {
        console.log("Unexpected error", error);
      });
    }
  };
}

Demo: https://codesandbox.io/s/serene-grass-vehq90?file=/src/App.tsx

Thank you!, that notation is quite interesting, could you explain it please? Why are not you using arrow functions?

[leapful]

@SalahAdDin : Sorry for the late reply. The reason of using "function" instead of "arrow function" is just for comforting Typescript checking as with "arrow function", Typescript is not sure that "<" will open a JSX tag or generic definition.

You still can achieve generic type with "arrow function" but with some weird syntax like:

const fn = <T, >() => {};

const fn = <T extends unknown>() => {}

but I would not recommend this way as it's confusing.

Referrer: https://stackoverflow.com/questions/41112313/how-to-use-generics-with-arrow-functions-in-typescript-jsx-with-react

[SalahAdDin]

@SalahAdDin : Sorry for the late reply. The reason of using "function" instead of "arrow function" is just for comforting Typescript checking as with "arrow function", Typescript is not sure that "<" will open a JSX tag or generic definition.

You still can achieve generic type with "arrow function" but with some weird syntax like:

const fn = <T, >() => {};

const fn = <T extends unknown>() => {}

but I would not recommend this way as it's confusing.

Referrer: https://stackoverflow.com/questions/41112313/how-to-use-generics-with-arrow-functions-in-typescript-jsx-with-react

Actually, I tried to translate it to an arrow function, I couldn't.

[trungh13]

@SalahAdDin , @sergey-sivchenko :

Since it's just a linting error from eslint rule, not typescript error, the last thing you can do is following its best practice to avoid potential issue, may be a promise handling wrapper like this:

function onPromise<T>(promise: (event: SyntheticEvent) => Promise<T>) {
  return (event: SyntheticEvent) => {
    if (promise) {
      promise(event).catch((error) => {
        console.log("Unexpected error", error);
      });
    }
  };
}

Demo: https://codesandbox.io/s/serene-grass-vehq90?file=/src/App.tsx

Amazing workaround.

For some want to have help neater code then you can make it as helper then

const { handleSubmit } = useForm()
const onSubmitHandler = () =>{
  // do something
}
....
<form onSubmit={onPromise(handleSubmit(onSubmitHandler))}>

[jamesarosen]

I love this solution!

I'll offer a few minor edits for clarity:

function withExceptionCapturing<T>(handler: (event: SyntheticEvent) => Promise<T>) {
  return (event: SyntheticEvent) => {
    if (handler) {
      handler(event).catch((error) => {
        console.log("Unexpected error", error);
      });
    }
  };
}

First, onPromise is quite vague. I changed it to withExceptionCapturing to describe the idea that we're taking in a handler and returning a handler with exception capturing.

Second, the argument to withExceptionCapturing isn't a Promise; it's a SyntheticEvent => Promise (a function that takes a SyntheticEvent and returns a Promise). Thus, I changed the name to handler.

You could go further and say that this doesn't even have anything to do with event handling or react-hook-forms at all. It's just about capturing dangling promises from functions. That might look like this:

function withExceptionCapturing<S, T extends any[]>(fn: (...rest: T) => Promise<S>) {
  return (...args: T) => {
    fn(...args).catch((error) => {
      console.log('Unexpected error', error);
    });
  };
}

And you'd use it the same way:

<form onSubmit={withExceptionCapturing(handleSubmit(onSubmitHandler))}>

But you could also use that one in other contexts:

// (number) => Promise<string>
function aSmallNumber(n: number): Promise<string> {
  return new Promise((resolve, reject) => {
    if (n < 0) reject("Can't be negative");
    if (n < 10) resolve('OK');
    reject('Too big!');
  });
}

// also (number) => Promise<string>
const aSmallNumberWithExceptionCapturing = withExceptionCapturing(aSmallNumber);

aSmallNumberWithExceptionCapturing(7);

[nirtamir2]

I notice this issue too.
Can we somehow use another exposed function that does not returns a promise / change

react-hook-form/src/types/form.ts

Line 597 in 8028e4d

export type UseFormHandleSubmit<TFieldValues extends FieldValues> = (

type to not return a promise?
It seems that all the solutions so far are just ignoring this ESLint rule / have non-idiomatic code

[paleite]

I suspect this is a bug in react-hook-form.
Here's the workaround:

Before:

      <form onSubmit={handleSubmit(onSubmit)}>

After:

      <form onSubmit={(...args) => void handleSubmit(onSubmit)(...args)}>

The bug: onSubmit expects a sync function that returns void, but handleSubmit is an async function returning void, hence why ESLint (correctly) identifies this as a misused Promise, and that's also why fixing it so ESLint doesn't complain (e.g. <form onSubmit={void handleSubmit(onSubmit)}>) breaks handleSubmit in a way that preventDefault is never called.

[leapful]

@kdubb

Rule no-misused-promises with option checksVoidReturn (option for the case in this discussion) is to prevent a asynchronous callback to be passed as an argument where the logic for that argument want call a synchronous callback, something like:

const setSafeMode = async () => {
   // Doing some asynchronous checking then set safe mode
}

const processData = ({ setSafeMode }) => {
   setSafeMode();
   doSomethingWithSafeMode();
}

=> The potential bug might happen because doSomethingWithSafeMode() is triggered before safe mode is being evaluated.

That's not the case when using with synthetic event like onSubmit, onClick, onChange, onBlur ...

If you see any leaking a Promise (i.e. errors produced by the promise are not handled) that can cause wrong logic handling by using async await on those event handlers, like:

<form onSubmit={async () => {
    await doSomething();
}}>
  ...
</form>

Please share it here to discuss. Otherwise, just use the config from typescript-eslint/typescript-eslint#4623 or wrapper function is enough.

The config example:

{
  "@typescript-eslint/no-misused-promises": [
    "error",
    {
      "checksVoidReturn": {
        "arguments": false
      }
    }
  ]
}

[kdubb]

Before we go further into that, can you explain the reasoning for handleSubmit generating a Promise returning function when onSubmit is typed to accept a void returning function? This seems non-sensical and of no added value.

By "fixing" handleSubmit to return a void returning function it will force anybody with this rule enabled to explicitly handle the Promise, which is what they are asking to be linted. For codebases without this rule enabled it seems nothing changes.

Asking to disable/diminish a pretty useful rule because handleSubmit is producing a function with the wrong signature seems odd.

[leapful]

@kdubb

Method handleSubmit is using async await to perform async validation logic and also trigger onValid or onError callback which can be an async callback too.

react-hook-form/src/logic/createFormControl.ts

Lines 1027 to 1077 in 1647bb2

	const handleSubmit: UseFormHandleSubmit<TFieldValues> =
	(onValid, onInvalid) => async (e) => {
	if (e) {
	e.preventDefault && e.preventDefault();
	e.persist && e.persist();
	}
	let hasNoPromiseError = true;
	let fieldValues: any = cloneObject(_formValues);
	_subjects.state.next({
	isSubmitting: true,
	});
	try {
	if (_options.resolver) {
	const { errors, values } = await _executeSchema();
	_formState.errors = errors;
	fieldValues = values;
	} else {
	await executeBuiltInValidation(_fields);
	}
	if (isEmptyObject(_formState.errors)) {
	_subjects.state.next({
	errors: {},
	isSubmitting: true,
	});
	await onValid(fieldValues, e);
	} else {
	if (onInvalid) {
	await onInvalid({ ..._formState.errors }, e);
	}
	_focusError();
	}
	} catch (err) {
	hasNoPromiseError = false;
	throw err;
	} finally {
	_formState.isSubmitted = true;
	_subjects.state.next({
	isSubmitted: true,
	isSubmitting: false,
	isSubmitSuccessful:
	isEmptyObject(_formState.errors) && hasNoPromiseError,
	submitCount: _formState.submitCount + 1,
	errors: _formState.errors,
	});
	}
	};

Since there is nothing wrong with it, changing might not bed needed. Furthermore, using async await on DOM event handler is a common pattern in React and updating a linter configuration is easier to solve this specific case.

[kdubb]

I must be missing something. Shouldn't handleSubmit catch those errors? Adding a catch clause to the currently returned function would ensure those errors update the form state accordingly. Then handleSubmit can return a void returning function wrapping that logic.

[paleite]

I've created a PR for this, which shows exactly where the issue is problematic. In the tests, it's assumed that if onValid throws an error, you need to catch it after handleSubmit has already been executed, i.e. if you use handleSubmit like the docs suggest, you're leaking a promise.

Case in point: https://github.com/react-hook-form/react-hook-form/pull/10924/files#annotation_14103380485

[demarchenac]

Are there any updates on the go-to implementation one should follow?

[demarchenac]

I'm asking since there seems to be an accepted answer on a similar discussion #9325:

Alright, I've done a little bit more research.

Check out this typescript-eslint/typescript-eslint#4623 PR that adds granular options within checksVoidReturns for the no-misused-promises TS ESLint rule; the attributes options was added specifically for use-cases like the one you're experiencing. This is the official TS ESLint solution and we recommend you update your .eslintrc config file with it:

"rules": {
  "@typescript-eslint/no-misused-promises": [2, {
    "checksVoidReturn": {
      "attributes": false
    }
  }]
},

[xenostar]

We need to continue the discussion around this. I just installed react-hook-form tonight and within 5 minutes of using it I'm jumping down a huge rabbit hole trying to "fix" this issue. I imagine many others are in the same situation considering this library and at this moment it almost feels more convenient just to uninstall it. That is a shame.

Changing my eslint rules is in my opinion an absurd "solution" to this problem since it is flagging a legitimate issue; this needs to be solved at the react-hook-form level.

I suggest we either:

1. Change the handleSubmit function implementation to be wrapped in one of the many suggested promise helper functions outlined here (and in Using ts-standard to validate TypeScript #9325 and Promise-returning function provided to attribute where a void return was expected. #8622) that handles the promise correctly.
2. Or, provide this wrapper function so it can be imported and we can wrap our handleSubmit with it. i.e.

<form onSubmit={handleSubmitHelperFunction(handleSubmit(onSubmit)} />

Personally, I vote for option 1 because I think users shouldn't have to think about this issue.

[zokins]

I agree with solution 1, it will make it easier for people to update their codebase if for example the eslint rule was added at a later date etc. Doing a previous comments hack worked best for me:
(...args) => void handleSubmit(onSubmit)(...args)

[bombillazo]

Has this issue been solved?

[poisshakatis]

No?

[SalahAdDin]

Let's create an issue then!

[bostrom]

FWIW I was using @paleite 's workaround for a while until noticing that the formState sometimes got reset when submitting the form multiple times (e.g. due to validation errors or error responses from the backend.)

I started using this instead, which has been working better

  import { FormEventHandler, useCallback } from 'react';
  import { FieldValues, useForm } from 'react-hook-form'; 
  import { Form, useSubmit } from 'react-router-dom';

  const submit = useSubmit(); // from react-router
  const { handleSubmit } =  useForm<SomeFormType>({
    // ...
  })

  const onSubmit = useCallback<FormEventHandler>(
    (event) =>
      handleSubmit((values: FieldValues) => {
        submit(values, {
          // submit your values somehow, here using react-router's submit
        });
      })(event),
    [handleSubmit, submit],
  );

  return (
    <Form
      method="post"
      onSubmit={onSubmit}
    >
      // ....
    </Form>
  );