So, why isn't useWatch pulling control from the context?

[ahkhanjani]

I tried to find an issue that mentioned this but I couldn't find any. Which is confusing me even more.

Is there a particular reason why useWatch can't use the control available from the context provider? Currently it errors if we don't manually give it the control. Why can't it be like the other hooks that use the context instead?

[tamish-max]

useWatch does pull control from context now, but only if the component is actually under FormProvider.

In the current implementation, it effectively does:

const formControl = useFormControlContext()
const { control = formControl } = props || {}

So this works:

<FormProvider {...methods}>
  <Child />
</FormProvider>

function Child() {
  const value = useWatch({ name: 'fieldName' })
  return <>{value}</>
}

If you still get an error, the usual causes are:

1. the component isn’t actually rendered inside FormProvider
2. there are multiple RHF contexts/copies involved
3. useWatch is being called in a place that renders before the provider exists

So I don’t think you should need to pass control manually in the normal FormProvider case.

[chrisjcthomas]

useWatch does read control from context — but only if that context exists.

From the docs: control is optional when you are using FormProvider. The hook itself does not invent a form; it either takes an explicit control or falls back to useFormContext().

What usually causes the error

1. No FormProvider above the component

// parent
const methods = useForm()

return (
  <FormProvider {...methods}>
    <Child />
  </FormProvider>
)

// child
function Child() {
  // control comes from context — no prop required
  const value = useWatch({ name: "email" })
  return <span>{value}</span>
}

If Child is rendered outside <FormProvider>, you get the missing-control error. Same for portals, dialogs, and storybook wrappers that remount outside the provider.

2. You only wrapped with a plain form, not the provider

// this does NOT create context
const { register, control } = useForm()
return (
  <form>
    <Child /> {/* useWatch() here fails */}
  </form>
)

Here you must pass control in (or switch to FormProvider).

3. Calling useWatch() with no args and no provider

Watching the whole form still needs a control source:

useWatch()                 // needs FormProvider
useWatch({ name: "x" })    // same
useWatch({ control, name: "x" }) // always fine

Why it feels different from other hooks

Hooks like useFormContext fail loudly when the provider is missing. useWatch needs control either as an argument or from that same context, so the failure mode looks like “I have to pass control everywhere” when the real issue is missing provider at that part of the tree.

Pattern that scales

• Root: const methods = useForm(…) + <FormProvider {...methods}>
• Deep leaves: useWatch({ name }) / useFormContext() with no props
• Reusable fields used with or without a provider: accept optional control and let the hook resolve it:

function PriceField({ control }: { control?: Control<FormValues> }) {
  const price = useWatch({ control, name: "price" })
  // …
}

If you still get the error with a provider in place, the next place to check is whether the watching component is under a second React tree (portal target, another root, test harness) that does not include the provider.

[ninaad-padiyarr]

One small correction to the portal advice above: rendering into document.body with createPortal() does not lose the form context. A portal stays in the same React tree, even though its DOM nodes appear somewhere else.

So if your input is in a modal, check how that modal is mounted. A normal portal created beneath FormProvider keeps its context. A separate createRoot() starts another React tree and needs its own provider or an explicit control.

React explains the distinction in the portal docs. That can save you from adding another provider when the portal itself isn't the problem.

AI-assisted reply; checked against the React documentation.

[ahkhanjani]

Thank you for your responses guys and sorry for the late reply. If I remember correctly, I meant to say TypeScript error not runtime. If I'm not mistaken, control is not optional for useWatch in the type system. I should have been more clear. If it already pulls control from context, the type should also be optional. Am I mistaken?

[nicholas-greenwood]

control is optional in the current useWatch types too, including when you pass name