The id field in useFieldArray is an anti-pattern, it should be renamed

[pfcodes]

Using id as the name for the key field is wrong. A lot of the time, forms deal with backend database resources, the unique identifier variable for these database resources are typically named id. useFieldArray is overwriting the id field of the backend resource with it's own variable and this forces us to use hacks to overcome this.

Why is the field that represents a key named id instead of key?

From the description for keyName:

Name of the attribute with autogenerated identifier to use as the **key** prop. This prop is no longer required and will be removed in the next major version.

Normally I wouldn't complain and just set keyName to something else, but the doc says the prop is going to be removed, leaving us with no escape of this anti-pattern.

[Sajarin-M]

I always make use of the keyName prop whenever I use a field array. Can someone please elaborate on why the keyName prop will be removed in the next major version and if there is something better coming to replace it?

[ehwarren]

I know I'm just bumping an old discussion here, but being unanswered and also being a breaking change in the future I just wanted to possibly spark further discussion on the topic.

I agree that the ability to alter the keyname should remain in the library, for the exact reasons as stated by OP.

[iurietarlev]

Completely agree with both @ehwarren and @Sajarin-M.

I think a more appropriate name for this would be key if it is decided that keyName does need to get removed, however that still means a breaking change for many people.

[AndrewIsh]

Agree with everything above. I feel that having any property name is liable to collide with native properties in the object being handled. So my vote is to keep keyName which removes the issue entirely.

[alvesvaren]

What is the reason it isn't internally wrapped like this?:

// Old:
{ id: string, value: string }

// New:
{ id: string, data: { value: string } }

Wouldn't this also allow for flat array fields (like string, number etc)? It would also never cause any conflicts..

There's a lot that feels way to complicated with the useFieldArray-hook, and it doesn't seem that though through compared to most other parts of this library.

There's probably a lot of good technical reasons for why it isn't done this way, but at least from my perspective as a user, this seems like a more intuitive way to do it, however this would probably be a breaking change