patterns for async validation + resolvers?

[biowaffeln]

Hey guys, I have a tricky situation that I ran into and I'm not sure what the best solution for that is. Here's the basic example that I'm starting with, it's a form that uses zodResolverto validate some name and password fields: Stackblitz Example

Now what I want to do is add an async validation for the username to see if it's already taken. The problem is, if I add it to the FormSchema, it will run the request every time, even if it validates the other fields. I tried adding it as a validation to register, but that doesn't seem to run if I supply the resolver. I guess I could validate the field myself by adding a watcher and calling setError manually, I was just wondering if there is a more idiomatic way to handle this that I'm missing?

[bluebill1049]

could you throttle the request inside the schema validation?

[biowaffeln]

You mean inside the zod schema? Yeah I can, but it will still do the request even if an unrelated field (like password or confirm) changes. You can see the problem when I change the password field, the updated error message only appears after the username validation resolved.

[bluebill1049]

I think you may have to build a custom resolver for this then, i believe we do provide field name for current validate field.

[sushanyadav]

Does this help?

https://stackblitz.com/edit/react-ts-t6jxgh?file=App.tsx

[bluebill1049]

Thanks for sharing.

[mrtnpro]

@biowaffeln I keep running into this issue over and over and couldn't come up with a reasonable solution myself yet, except what you have already experimented with and throttling like @bluebill1049 suggested.

My current approach for async validations is quite cumbersome to maintain: I do basic vailidations (type, length, ... basically anything I can capture by regex) by zod schema and then proper async validations against an API on component level, passing validation states back and forth between <input/> and <form/> in order to block the UI (submit buttons etc) if async validation fails.

Have you come up with a better approach yet?

[biowaffeln]

I eventually moved to a different library, this was still one of the big unresolved pain points for me.

[inclinedadarsh]

which library do you use now?

does it support Zod or Yum and async validation?

[craigmcc]

I use Yup for a very similar use case (detecting whether a Library name is already in use). The Yup rule looks like this:

        name: Yup.string()
            .required("Name is required")
            .test("unique-name",
                "That name is already in use",
                async function (this) {
                    return validateLibraryNameUnique(ToModel.LIBRARY(this.parent));
                }
            ),

A couple of notes about this usage:

• I use "onBlur" for the validation mode, so this triggers when you leave the name field, AND when the submit happens.
• The validateLibraryNameUnique() function does an async fetch to the server, with an await inside, so from the RHF viewpoint this is just a synchronous validation like any other. It also means, of course, your input to subsequent fields will wait for this to either succeed or fail.
• Why pass the this.parent thing (i.e. the entire model object being validated)? It started as a pattern where some of my validation rules required access to more fields than just the field being validated. In this particular case, it is important on an update -- if you are updating an existing record (but don't change the name) it will of course be in use. The validation logic passes along the id of the model object being validated, which will not be there on a new Library being created, but will be there for an existing one being updated.

From the docs I've read on Zod, it can do something similar, but I've never tried it.

If your link to your server is slow, and you really want the validation to be asynchronous, then of course this pattern won't help much.

[OmarMoataz]

Is there a way in react-hook-form to figure out that this field specifically changed? because I don't think it should be the responsibility of the backend I am calling to handle that case. Without the backend being able to check, there should be a way to figure out that this value specifically changed. My problem is two-fold, the validation schema in it's entirety gets called onChange even though I've specified mode onBlur and I can't seem to handle the edit case either.

[isaac-scarrott]

Also having this issue, so would like to bump it. Wanting to implement in a similar way and can't because it validates the schema onChange rather than using the mode I specified

[lennerd]

I solved this via a special useRefinement hook. Here is an example on how to use it:

https://stackblitz.com/edit/vitejs-vite-x1cial?file=src%2Fuse-refinement.ts

Let me know, what you think!

[codepunkt]

This is dope! Could you publish it as a small library that we could fine-tune as a community if we ever ran into problems with it - or open a PR on hook-forms' zod resolver to also include this?

[lennerd]

Thanks for the great feedback! Though I think the useRefinement hook is really more a hack than a library. Since the last time dealing with this I moved to conform. Great type safety and a great form library when you work with Remix or Next.

Their also is a great page about how to have async refinements in conform: https://conform.guide/validation#async-validation

[codepunkt]

Alright, thanks! 👍🏻
I'm rarely using anything server-side rendered, so I didn't look at conform any closer.

[jwtong]

How would you use this if you wanted to pass a custom message back (superRefine?)

[lennerd]

You can use the function returned from the useRefinement inside your superRefine calls. useRefinement is really just a cached return value with some invalidation logic.

[jonashex]

I have a similar issue: Some of my fields need to be validated by sending a request to some validation server and I'd like to avoid sending those requests on all changes of unrelated fields. It would be nice to be able to let it behave like: Only validate on submit and on changes the specific field.

[lennerd]

Why not using async validate functions inside your useController and register calls then? They are only triggered if their corresponding fields change.

[jonashex]

One of the fields was using a Controller already but this didn't make a difference. Also tried a minimal setup with no success but maybe I misunderstood your suggestion:

const contentController = useController({
  name: 'content',
  control,
  rules: { validate: async () => {
    console.log("triggered")
    return true
  }}
})
  
<input
  name={contentController.field.name}
  onChange={contentController.field.onChange}
  value={contentController.field.value}
/>

// more inputs, all trigger `contentController` validation.

[lennerd]

Just to be sure: you use this code in a standalone component, right?

[jonashex]

I'm not exactly sure what you mean by standalone component, however, I narrowed down the issue and think it's solved for me now. The form validation was triggered on all fields as soon as I used formState: {isValid} from the methods. I guess it makes sense that the from must be fully validated for isValid to know it's actually valid. But is it really required to re-validate fields that haven't changed? Would you say this behavior is expected? Anyways, thank you a lot for your support!

[lennerd]

Hmm, still sounds wired. Do you think you can copy a bit more code from your form? The component surrounding useController would be especially helpful.

I ask because the problems you describe sound like you‘re using useController and useForm in the same component. Happens to me once. 😬 Either way a bit more code to reproduce your problem would be great!

[jems-payreto]

Does it works on Controller component with multiple MUI Textfields?

[slaymance]

If you use a validation library that allows contextual validation like Yup or Joi, please upvote the feature request #11960 and its associated pull request #11961.

The idea with this feature request is for the library to provide the validation event ('change', 'blur', or 'submit') that triggered the schema validation to the context object passed to the resolver. We could then perform specific validations on certain events.

Note that Zod does not support contextual validation (see this issue).