Controllers would strongly benefit from clear documentation on how they watch values (exact)

[marcebdev]

I guess I'm running into a more unique use case where I'm editing items in an object (keyed by id), rather than an array, this is so I can decouple what a form item is from the actual UI. (so useFieldArray isn't there to help/save me, though there are use-cases that useFieldArray may not work with either.

Anyways, it's just today I realized a big part why Controllers might not play nice in setups that have nesting or parent/child editing is that Controller actually reads updates a lot more like an event bus it seems by default. It seems like this was the only behavior until very recently. This was pretty surprising since my understanding was Controller was to adapt to a controlled component in React. Did not realize for an (admittedly neat) optimization that this was actually not true and it was not correct to assume Controlled aligned with how React works.

I think the exact prop/arg deserved a big mention in the docs, but honestly even before this prop being exposed, it would've been extremely helpful & useful to know this. Anyways, I'm lucky and appreciate having this functionality now, but this would really benefit from being a clear concept to anyone using the library rather than a rabbit hole. It's also a neat thing to know bc without knowing this is how Controller's work, I would've never fully realized it's a nice little optimization than can help with some watches where you want to reduce the subscription down to the specific path/event vs an equality check.

[chrisjcthomas]

Your observation about how Controller and useWatch operate under the hood is spot on.

The Underlying Subscription Model

React Hook Form decouples form state from React's component tree by maintaining values in an external store and notifying subscribers via an internal Subject/Observer event bus (control._subjects.values).

When a component subscribes via Controller or useWatch, the subscription matching algorithm defaults to prefix / fuzzy path matching (exact: false).

If you have a nested dictionary structure like:

type FormValues = {
  items: Record<string, { title: string; completed: boolean }>
}

Updating items.item_1.title emits a notification along the path. By default:

• A subscriber on items is notified (as the parent).
• A subscriber on items.item_1 is notified.
• Sibling subscribers that share prefix substrings or non-exact match patterns can be evaluated.

This prefix behavior is designed to make parent summary components automatically re-render when any child field updates (e.g. updating an array item updating a form-level validation or total). But in a dictionary of independent entities (Record<string, Entity>), it causes cascading renders across unrelated fields.

Using exact: true with Dictionaries

Setting exact: true restricts the subscription callback so it only triggers when the mutation matches the specific field path:

<Controller
  name={`items.${id}.title`}
  control={control}
  exact={true}
  render={({ field }) => (
    <input {...field} />
  )}
/>

When exact: true is set:

• Changes to items.${otherId}.title or items.${id}.completed will not trigger this controller.
• The observer does a strict string equality check on the updated path rather than a prefix match.

Isolating Dictionary Rows

When building dictionary/table interfaces without useFieldArray, combining exact: true with isolated row components keeps performance optimal:

interface ItemRowProps {
  id: string
  control: Control<FormValues>
}

function ItemRow({ id, control }: ItemRowProps) {
  return (
    <div>
      <Controller
        name={`items.${id}.title`}
        control={control}
        exact={true}
        render={({ field }) => <input {...field} placeholder="Title" />}
      />
      <Controller
        name={`items.${id}.completed`}
        control={control}
        exact={true}
        render={({ field: { value, onChange } }) => (
          <input
            type="checkbox"
            checked={!!value}
            onChange={(e) => onChange(e.target.checked)}
          />
        )}
      />
    </div>
  )
}

Summary of Subscription Modes

Mode	Behavior	Best Used For
exact: false (Default)	Matches on field path and any child/parent prefix mutations	Form sections, summary displays, array lengths
exact: true	Re-renders only when that precise path is modified	Large entity dictionaries, table cell inputs, isolated field controllers

[Mike-Animal-Counseling]

The current v7 docs now cover this explicitly. One detail worth correcting in the reply above: in 7.91.0, Controller/useController default to exact: true. useWatch has a different default. The controller passes that option to its value and form-state subscriptions (source).

Also, since 7.81.0, exact: true isn't simply a strict equality check. It matches the subscribed path and updates to its ancestors, but not updates below it. For example:

Watch items.a.title, set items.a        -> matches
Watch items.a,       set items.a.title  -> does not match with exact: true

That second case matters when a controller represents an entire object but another input edits one of its children. If that controller should update for child edits, use exact: false on it:

useController({ control, name: `items.${id}`, exact: false });

The matching implementation makes the distinction explicit. These are subscription rules; they don't prevent renders caused by the surrounding React tree.

I checked the examples with real hooks on RHF 7.91.0 / React 19.3.1: the object controller kept its old rendered value after a child update with the default option, updated with exact: false, and a leaf controller updated after replacing its parent object.

AI-assisted; those hook cases were run locally.