feat(conform-react): custom revalidation

[edmundhung]

Resolves #125

This introduces two new config on the useForm hooks:

function Example() {
  const [form, { email, password }] = useForm({
    // This is now deprecated in favor of the new config
    initialReport: 'onBlur',

    // Define when Conform should start validation. Default `onSubmit`.
    shouldValidate: 'onBlur',

    // Define when Conform should revalidate again. Default `onInput`.
    shouldRevalidate: 'onBlur',
  });
}

[codesandbox]

  Open in CodeSandbox Web Editor | VS Code | VS Code Insiders

[cloudflare-pages]

Deploying with    Cloudflare Pages

Latest commit:	2717524
Status:	✅  Deploy successful!
Preview URL:	https://c021d815.conform.pages.dev
Branch Preview URL:	https://custom-revalidation.conform.pages.dev

View logs

[danestves]

This is definitely something that we need 👀

[edmundhung]

This is definitely something that we need eyes

This is ready to be merged and released. The only thing that stop me is deciding a proper default for shouldRevalidate. From a progressive enhancement perspective, the default should be onSubmit which is the default behaviour of a HTML form. But most of the users will prefer onInput for a modern validation experience and the config becomes a boilerplate that the developer has to repeat everywhere. 😓

const [form, { email, password }] = useForm({
    // setting these everywhere (?)
    shouldValidate: 'onBlur',
    shouldRevalidate: 'onInput',
});

What do you think? @danestves

[danestves]

From a progressive enhancement view I prefer to default always to on submit, why? I really think most of the user will use just the default and only a few will change it to onInput, at enterprise level most of the devs will use the onSubmit @edmundhung

[edmundhung]

@danestves For first submission, yes. I am fine having onSubmit as the default of shouldValidate.

Maybe it was a misconception I had. But I used to have all my forms revalidating fields with error as I type and as it gives user an instant feedback on whether the error they had is resolved or not.

This is the same as react-hook-form. They used onChange (onInput) as the default for its reValidateMode config.

Another approach could be having a different default based on whether client validation is defined or not. If defined, default to onInput. If not (i.e. server validation only), default to onSubmit.

[danestves]

It depends on the type of application that you want to build, for example, in two of our apps that behavior doesn't like to product and designers, and from a A/B test, users want the validation only on submit 😅

cc @edmundhung

[danestves]

Another approach could be having a different default based on whether client validation is defined or not. If defined, default to onInput. If not (i.e. server validation only), default to onSubmit.

I think this is the way 👀 we just delete the client validation to avoid having client validation and depend entirely on the server (project requirement 😅)

cc @edmundhung

[edmundhung]

@danestves I am actually convinced to have both config default to onSubmit regardless of validation mode for now. But then noticed this would becomes a breaking change. 🙄

I don't have much changed yet so I feel a bit bad if I bump the major version to 0.7 now. I might keep it default to onInput so I can released it as 0.6.1 first and fix the default later.

[danestves]

@danestves I am actually convinced to have both config default to onSubmit regardless of validation mode for now. But then noticed this would becomes a breaking change. 🙄

I don't have much changed yet so I feel a bit bad if I bump the major version to 0.7 now. I might keep it default to onInput so I can released it as 0.6.1 first and fix the default later.

Sounds really good! Like that approach, actually. Like the 10x engineers say, LGTM

[edmundhung]

LGTM!