Hey @noritsune thank you for the issue! I think I understand the problem here. While the useForm hook from @refinedev/core exposes an onFinish handler to submit values and doesn't integrate with forms automatically, having a single generic TVariables is enough but when we extend the useForm with form libraries (such as react-hook-form) it's understandable to require two generics, lets say TVariables and TSubmission, one is working with the form elements and other can be used to type onSubmit function to make sure the specs are met.

The 4th generic can be the same with the 3rd by default and it will also only trigger errors if onSubmit (or equivalent) is used manually. We can use type casting to prevent errors internally and assume users know what they're doing when they provide the 4th generic 🤔

Do I understand it correctly?

BTW, as a workaround I remember that one time I used a union type as 3rd that matches both the form and submission type and handled types in the custom onFinish/handleSubmit handler but having an option of a 4th generic looks better to me 😅

@aliemir Thank you for your response. I think your understanding is correct. Also, I've mostly grasped what you're saying. So, are you suggesting that useForm should allow specifying the type of the onFinish function's argument (i.e., the type of data sent to the DataProvider) as the 4th type option?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

+1

It's really hard to use TS without proper typing in here.
Also, thanks to @aliemir for the workaround.

I think it's better to use union type rather than "any"

Hopefully we can get an enhancement on this soon.

@chhaysotheara thank you for bumping the issue 😅 I'm leaving this comment as an implementation guide that we can follow when working on this feature.

Using a union type for TVariable works but doesn't enforce anyone of the types and can allow corrupted values. For now this can be used as a workaround.

As I mentioned earlier, one more generic can be added but even now the generics are too crowded imo. Instead, now I'm more into having utility types to manage two of the generics in one. This will also allow us to continue accepting TVariables like now without any issues (we don't always need to customize them in handleFinish or onFinish).

We can create one utility type CreateFormVariables<TForm, TSubmission> like below:

// using symbols to avoid conflicting with the basic TVariables shape
const FormVariablesSymbol = Symbol("FormVariables");
const SubmissionVariablesSymbol = Symbol("SubmissionVariables");

export type CreateFormVariables<TFormVariables, TSubmissionVariables> = {
  [FormVariablesSymbol]: TFormVariables;
  [SubmissionVariablesSymbol]: TSubmissionVariables;
};

Then we can allow passing the TVariables (3rd) generic as an object or return type of CreateFormVariables, then we'll extract the appropriate types via something like below:

type ExtractFormVariables<T> = T extends { [FormVariablesSymbol]: infer F } ? F : T;
type ExtractSubmissionVariables<T> = T extends { [SubmissionVariablesSymbol]: infer S; } ? S : T;

Then in the implementation we can use those types and achieve this:

type Data = { id: number; name: string; date: string; }
type FormValues = { name: string; }
type SubmissionValues = { name: string; date: Date; }

const { handleSubmit, refineCore: { onFinish } } = useForm<
  Data,
  HttpError,
  CreateFormVariables<FormValues, SubmissionValues>
>({ ... });

// `values` will be in `FormValues` type
handleSubmit((values) => {
  // `onFinish` will expect the argument to be in `SubmissionValues` type and will error if it doesn't match.
  onFinish({ ...values, date: new Date() });
});

As you can see from the extraction utilities, current implementation is also supported with no changes:

type Data = { id: number; name: string; }
type FormValues = { name: string; }

const { handleSubmit, refineCore: { onFinish } } = useForm<
  Data,
  HttpError,
  /// this will continue working as expected
  FormValues
  // or
  // FormValues | SubmissionValues
  // will continue working as is
>({ ... });

CreateFormVariables, ExtractFormVariables and ExtractSubmissionVariables can be exported from @refinedev/core and can be used in the related form packages (@refinedev/antd, @refinedev/react-hook-form and @refinedev/mantine).

Let us know what are your thoughts on this. We can include this in our roadmap for the upcoming improvements and features to Refine. We're currently at planning stage for this. Or if anyone is interested in working on this issue, they can use this comment as a guide. We'll happy to help to the contributors 🚀 🚀

hey @aliemir I’ve read through the discussion and I’d love to take on this issue. Thank you for the detailed implementation guide. I will go over it and fix it soon 🚀