issue: useWatch names doesn't respect exact, can't work with nested/indexed form

[don-hover]

Version Number

7.12.2

Codesandbox/Expo snack

n/a

Steps to reproduce

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behaviour

@bluebill1049

Bill,

In the RHF docs for useWatch, it shows an option for exact:

exact | boolean = false | This prop will enable an exact match for input name subscriptions.

This makes it sound like the default behavior is that provided field names in the {name: ['fieldX', 'fieldY']} option would be matched non-exactly. I've looked at the source code, and I don't see any reference to the exact prop - it looks like the watched field names are always matched directly by the provided field name props.

This is causing a problem with nested form objects, because a) there's no way to provide the exact name of a dynamically-generated nested field, and b) the current logic won't match such a field by the static part of the name.

As an example, we have a table that is represented in RHF with fileds like this:

    <EditableInput {...register(`${listItem.id}.quantity`)} />

So, the actual nested field name will be something like 1234.quantity, 1235.quantity, etc.

How can we make this work with the useWatch option for name?

What browsers are you seeing the problem on?

Chrome

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[bluebill1049]

please follow the issue template when you report an issue. https://github.com/react-hook-form/react-hook-form/search?q=exact

[don-hover]

@bluebill1049

Thank you, I do see in the source code now that exact is used in shouldSubscribeByName.

I still have a question though, of how can a dynamic form field name be watched by name, for a form field like this?

<EditableInput {...register(`${listItem.id}.quantity`)} />

The implementation that I see of shouldSubscribeByName is:

(
  name?: T,
  signalName?: string,
  exact?: boolean,
) =>
  exact && signalName
    ? name === signalName
    : !name ||
      !signalName ||
      name === signalName ||
      convertToArrayPayload(name).some(
        (currentName) =>
          currentName &&
          (currentName.startsWith(signalName) ||
            signalName.startsWith(currentName)),
      );

so this looks like when using exact: false the code checks if the fieldname starts with the provided name. That's not really non-exact, and that would not work with the typical scenario of a dynamic key prefix for a fieldname. I think that this code should really be using includes instead of startsWith, like:

(
  name?: T,
  signalName?: string,
  exact?: boolean,
) =>
  exact && signalName
    ? name === signalName
    : !name ||
      !signalName ||
      name === signalName ||
      convertToArrayPayload(name).some(
        (currentName) =>
          currentName &&
          currentName.includes(signalName) ),
      );

If this code is changed to use includes instead of startsWith, then I think it will solve the case for dynamic/nested fieldnames.

Also, should the code be doing this check?

 (currentName.startsWith(signalName) ||
            signalName.startsWith(currentName))

If we say watch('firstName', {exact: false}), I do think we would want to match a field fullFirstName or ${.id}.firstName from currentName.includes(signalName); but I don't think we would want to match a field fir from signalName.startsWith(currentName), or a field name from signalName.includes(currentName).

What is the usecase this part of the match is addressing?

Thanks,
Don

[bluebill1049]

I wouldn't go with includes, as it would grab more irrelevant results. with exact it works as a simple filter, it is simple and faster without convoluted logic within.

[don-hover]

@bluebill1049
So to clarify:

If I have this example, using nested object form data -

 <EditableInput {...register(`${listItem.id}.quantity`)} />

and I provide a watch config of watch(['quantity'], {exact: false}), should I expect that my field ${listItem.id}.quantity will be matched with quantity? I don't think this will match - because they don't both start with the same shared prefix.

This is why I suggested that includes is what is needed here, to support the nested data use case. If not, then how do you suggest for us to be able to what nested fields with dynamic keys like this?

Thanks.

[bluebill1049]

no, it wouldn't. Unless we start to support regex.

[don-hover]

@bluebill1049

If I have this example, using nested object form data -

<EditableInput {...register(${listItem.id}.quantity)} />
and I provide a watch config of watch(['quantity'], {exact: false}), should I expect that my field ${listItem.id}.quantity will be matched with quantity?

no, it wouldn't. Unless we start to support regex.

Shouldn't it, though? If I'm specifying non-exact mode, and the actual fieldname contains the fieldname value that I provided to watch, then intuitively this seems like we should expect a match and the field would be subscribed. If this isn't working, then how can I watch a specific field in a nested form data structure? All of the docs show that nested forms are a supported part of the RHF library, but it seems like watching a field of a nested form isn't supported.

Thanks,
Don

[don-hover]

@bluebill1049

Is there any further thought on this issue?

I have a complex application that uses an object-based nested form data structure, and this limitation that I'm describing basically means that I can't use useWatch unless I want to watch every field in the form - which I definitely don't want to do.

Is there a solution that you can provide, if I'd like to be able to do this?

Either this (preferred):

const watchedFields = useWatch({control, name: [
 '*.name', '*.quantity', '*.color',
]});

Or this (non-preferred):

const watchedFields = useWatch({control, name: [
 '123.name', '123.quantity', '123.color',
 '124.name', '124.quantity', '124.color',
 '125.name', '125.quantity', '125.color',
 '126.name', '126.quantity', '126.color',
]});

Since a nested form data structure is supported in RHF for registering fields, this really needs a solution so that the registered fields can be watched.

[don-hover]

@bluebill1049
Bill,

Here is some more information that I've found.

It looks like my second, non-preferred approach partially works in RHF.

If I implement a useWatch() like this:

Then the result that I see in the watchedFields provided by the hook is:

So unlike calling useWatch without a names option where I would see the normal object keys with watched values, in this case I'm seeing a numeric-indexed array containing the watched values - so there's no way of identifying which filed the values are associated with. Make a minor change to the code here to return the keys of the source fields would resolve that and significantly improve the usefulness.