Is there any good way to make react-hook-form work with async validation + zod superRefine?

[alex-collibra]

I have a pretty valid usecase, in my opinion: we need to send a value to backend, then backend does some validation and returns an error code back.

I tried a lot of different things, without luck so far. As validation relies on BE response, I believe superRefine is the only way to do it.
However, I faced a lot of issues.

1. without debouncing it makes request on each keystroke
2. there is a need to compare prev value to new value - otherwise it will run refinement on the field, even when unrelated fields change and cause a ton of networks requests
3. even with debouncing it still doesn't work well. In some cases, the error just doesn't appear, even though in resolver it is added to errors object (Probably smth to do with rerendiring timing)
4. With debouncing, if you change the field, then change unrelated field, sometimes, error is not shown at all while isValid flag is false.

The closest behaviour I could get to so far is using this example #40 (comment)

However, it is still causing an issue with #4 when isValidating becomes enabled, when it shouldn't.
Has anyone every had any luck with making it work? It seems like a lot of pain for smth relatively common 😔

[Phibee]

Hi @alex-collibra,

Here's my way of doing it.
https://codesandbox.io/p/sandbox/async-sky-57gfzk

Hope this would help!.

Things to Note:

1. Instead of superRefine, I just used refine.
2. Instead of usual zodResolver(schema), I passed additional arguments.
   Reference: https://github.com/orgs/react-hook-form/discussions/10545 by @leapful
   ex. zodResolver(authFormSchema, { async: true }, { mode: "async" })
3. I used RHF's Controller. reason is easy to adjust and put additional logic to it such as adding debounce.

[kensaadi]

This is exactly where forms get painful in modern React.

Async validation against a backend is a very common use case, but putting it inside zod superRefine/resolver can quickly become hard to control.

The problem is not only validation itself, but also:

• debounce
• stale requests
• unrelated field changes triggering validation
• isValid / isValidating timing
• UI errors not always matching resolver output

In my experience, backend validation is often better treated as an explicit field-level/domain check, not hidden too deeply inside the schema resolver.

Schema validation is great for synchronous structure/rules.
Remote validation usually needs its own lifecycle.

[yudin-s]

I would avoid putting this kind of backend check inside superRefine unless the whole form really depends on that remote result.

A schema resolver is a great place for local, deterministic validation. A backend uniqueness/eligibility check has a different lifecycle: debounce, cancellation, stale responses, loading state, and often “only validate this one field”. Hiding all of that inside the resolver is what usually causes the isValidating / stale error behavior you described.

The pattern that has been the least painful for me is:

• keep Zod for sync validation
• watch only the field that needs remote validation
• debounce it
• abort or ignore stale requests
• use setError / clearErrors for the remote result

Sketch:

const username = useWatch({ control, name: "username" })

useEffect(() => {
  if (!username) return

  const controller = new AbortController()
  const timeout = window.setTimeout(async () => {
    const result = await api.checkUsername(username, {
      signal: controller.signal,
    })

    if (!result.available) {
      setError("username", {
        type: "remote",
        message: "This username is already taken",
      })
    } else {
      clearErrors("username")
    }
  }, 400)

  return () => {
    controller.abort()
    window.clearTimeout(timeout)
  }
}, [username, setError, clearErrors])

If the remote validation must block submit, run the same backend check in handleSubmit too. The field-level check gives good UX, and the submit-time check is the final authority. That keeps Zod simple and avoids unrelated field changes triggering network validation.

[kensaadi]

I agree with the main idea: remote validation should usually not be hidden inside the schema resolver.

But I would be careful with this implementation pattern.

useWatch({ name: "username" }) re-renders the component using it every time username changes. If this logic lives inside a large form component, every keystroke now re-enters the React render lifecycle just to orchestrate remote validation.

For me, this should be isolated at field level or inside a dedicated validation hook.

The API function should stay outside the component as a pure service function, while the validation trigger can be wrapped in useCallback inside the hook/component, with the correct dependencies.

async function checkUsernameAvailability(
  username: string,
  signal?: AbortSignal
) {
  return api.checkUsername(username, { signal });
}

const validateUsername = useCallback(
  async (value: string, signal: AbortSignal) => {
    const result = await checkUsernameAvailability(value, signal);

    if (!result.available) {
      setError("username", {
        type: "remote",
        message: "Username already taken",
      });
    } else {
      clearErrors("username");
    }
  },
  [setError, clearErrors]
);

The cleaner flow would be:

• schema/resolver for local deterministic rules
• isolated useWatch only where the field validation is needed
• pure API function outside React
• stable validation trigger with useCallback
• debounce the trigger, not the whole effect body
• handle abort/stale requests inside the validation hook
• expose the result to RHF with setError / clearErrors

Otherwise we avoid complexity in the resolver, but we move debounce, timers, async request lifecycle, stale responses, abort logic and error synchronization directly into React components.

In my opinion, the real solution is not “resolver vs useEffect”, but a dedicated field-level validation lifecycle.

I’ve been working on this exact problem space while building Dashforge, a form framework built on top of MUI + RHF for large enterprise forms with field dependencies/reactions, and these orchestration problems appear very quickly at scale.