Rename id in useFieldArray to something more unique to react-hook-form

[Rc85]

Is your feature request related to a problem? Please describe.
If the array is populated by data from a database, the data most likely has an id field. useFieldArray generates its own UUID as id and it overwrites this property. Imagine if I have a delete button for every item in the list and sends a delete request to the server using the id, the server would not find this id because it's generated and overwritten by useFieldArray

Describe the solution you'd like
Rename id to something like _id or even something more unique like rhf_id.

Describe alternatives you've considered
All my tables in the database have a id as primary key. I could rename all of them, but seriously.

[Rc85]

Not sure why I use useFieldArray to begin with. Resorting to getValues.

[Moshyfawn]

You can rename the field array id prop to whatever you need with the keyName prop

const { fields } = useFieldArray({
  keyName: "customId"
})

fields.map(field => field.customId)

[Moshyfawn]

Additionlay, from v7.23.0, the keyName prop is no longer needed, as RHF won't override your id prop.
From the RHF useFieldArray docs section:

This prop is no longer required and will be removed in the next major version

[pauldmps]

I am using v7.52.1 and its still overrides the id field.

[bombillazo]

Yup, it is still overwritten

[Rc85]

I think you misunderstood the docs. The keyName prop is being removed and id will be used, which is an auto generated UUID.

useFieldArray automatically generates a unique identifier named id which is used for key prop. For more information why this is required: https://reactjs.org/docs/lists-and-keys.html#keys

I am using version 7.34.2 and am getting the id prop messing up with my delete request.

[davidspiess]

Same problem, i already have an id prop in my objects and they are overwritten by an autogenerated UUID. This bit us already so many times.

[Moshyfawn]

#8935 (reply in thread)

[pfcodes]

Same issue here. This feature wasn't designed for forms in an "edit" mode.

[Moshyfawn]

Please, check out this csb and see if you repro the issue.

[Moshyfawn]

Here's a working example

<button
-  onClick={() => handleAddAge(d.name === "Lisa" ? "000" : d.id)}
+  onClick={() => {
+    const id = getValues(`people.${i}.id`);
+    handleAddAge(d.name === "Lisa" ? "000" : id);
+  }}
>
  add age
</button>

[Rc85]

Ok, I get it now. This should probably be documented as someone who is new to the library will not know. I personally spent quite some time on it and was pulling my hair out. Thanks.

[Moshyfawn]

Fair, I'll look into documenting OG field id retrieval + explanation. Thx for the feedback

[davidspiess]

Thanks for the example @Moshyfawn. This was not clear to me too.
Nevertheless i think it would be better to overhaul useFieldArray in a major release and make it more intuitive, seeing that many fall into the same trap.

[xeeds]

Thanks for great explanation and examples.

[charlestbell]

@bluebill1049 How do I get useFieldArray to use the id field in my data without overwriting it?

I could make a separate, _id or key field using keyName, but then when I save my data to the server, it is included, so I have to strip out that extra _id / key field somehow. Do you know of a better way I could be doing this?

[charlestbell]

I'd be fine if useFieldArray creates new uuids when I append new items, because in fact it would need to, but I just don't want it to overwrite loaded data.

[Moshyfawn]

For sure, that's what I meant when I wrote _id or key, those were possible renames of id, but that wasn't the issue.

The issue is that useFieldArray is adding data to my data. I don't want it to do that. And since my data already has an id field called id that is created with the same uuid library that useFieldArray uses, I'd like the option to re-use my id field as the key, instead of adding a seperate key field, which dirties my data.

Because as it is right now, if I try to re-use my id field, useFieldArray overwrites it with a new uuid, which breaks the whole app, because now none of the ids match what's on the server.

What RHF version are you using, @charlestbell?

[bluebill1049]

all you have to do is just change the keyName prop to key and use field.key instead

[charlestbell]

@Moshyfawn "react-hook-form": "^7.34.2",

[pfcodes]

all you have to do is just change the keyName prop to key and use field.key instead

According to the docs: "This prop is no longer required and will be removed in the next major version."

So this solution is temporary

[charlestbell]

@bluebill1049 I don't think you understood the issue.

When I get the data after the form is submitted with the data from handleSubmit, passed to my onSubit function, the keys are still in it! The data is dirty. That is the issue. Dirty data.

[bluebill1049]

provide a simple codesandbox

[charlestbell]

It comes back to my original post, where I said the keys had to be "stripped out". I was expounding on that issue.

[leapful]

@charlestbell : Could you please provide the codesandbox that can re-produce you issue ? Because the normal handling of "useFieldArray" does not include unique identifier to original data.

For example, this codesandbox https://codesandbox.io/s/react-hook-form-usefieldarray-forked-p9jje4?file=/src/index.js had no unique identifier when submitting the form.

[charlestbell]

@bluebill1049 @leapful Here is a codesandbox of the issue.
https://codesandbox.io/s/usefieldarray-altering-ids-2hlegl?file=/src/App.js

First, it loads the data called 'dataFromApi', and loads it into useFieldArray, then, useFieldArray overwrites all the ids.
If I were to save the data back to the server, all the ids would be changed.
I made console.logs on lines 19 and 20 that show the issue.

I also made a codesandbox that uses the keyName prop
https://codesandbox.io/s/usefieldarray-where-keys-dirty-the-data-zi4jd2?file=/src/App.js

Check the logs on lines 20 and 21, and you'll see the outgoing objects are altered from the incoming ones

Object before:

{id: "417554a1-e998-4aa5-9096-3c761b5e4ef6", first_name: "Anna", last_name: "Culp"}

Object after:

{id: "417554a1-e998-4aa5-9096-3c761b5e4ef6", first_name: "Anna", last_name: "Culp", key: "ae478f10-62bd-4859-89d7-e585623904eb"}

So if I were to save the data back to the server, the 'key' prop would be added to all of my objects, hence what I said about dirtying the data.

Now, you could just ask the users to clean their own data, but may I offer a solution?

I think that a check could be implemented on incoming data with the key of 'id', that checks if it is already in a uuid/guid-type format, and if it is, will use it instead of overwriting it.
Additionally, a destructurable variable like 'cleanFields', or something like that from useFieldArray, that gives data 'pre-stripped' if any key fields.
Something like this:

  const { fields, cleanFields } = useFieldArray({ 
    keyName: "key",
    control,
    name: "items"
  });

const saveData = () => {
await fetch(url, { method: 'PUT', body: JSON.stringify(cleanFields) } // Makes saving the clean data easy
}

render (
// Still use fields for rendering
)

I just think it would improve the dev experience. Thoughts?

[leapful]

@charlestbell

The prop fields returned from hook useFieldArray is not a part of form values, it's an controlled array to to work with dynamic fields via loop.

If you want to get form values which includes the dynamic field values belongs to this prop "fields", you should use method getValues from useForm or via onValid callback of method handleSubmit.

Example (Click on submit button): https://codesandbox.io/s/usefieldarray-altering-ids-forked-dxten5?file=/src/App.js

[charlestbell]

That makes sense now. Thank you for explaining it.

[bluebill1049]

thank you @leapful 🙏

[bluebill1049]

Detailed answer > #8935 (reply in thread)

[axelnormand]

rather than the solution above (thank you for explaining), I wonder if it's conceptually easier to keep the keyName argument?
I've been using keyName to avoid having to think about when to use getValues

Any thoughts anyone?

And thanks for this library.

[AdventureBear]

I think keeping keyName is the easiest solution, it's a 1 line solution that works.

[martinjuhasz]

I also see a usecase for keyName and using useFieldArray in general over watch or getValues.
If you deal with arrays, its nice to have these helper functions designed for arrays that useFieldArray provides like append, prepend, remove, etc. You would have to do this manually otherwise.

[snoop088]

Hi all I am a bit worried here. If keyName is in fact removed from future versions as mentioned in the documentation, what would be the best way to use the update helper method of the fieldArray which requires an object type argument presumably with the shape of the field being updated. This type most likely already has an id property and if we are using field property of the fieldArray as the base data having some props updated, id gets silently overwritten as mentioned by @charlestbell. Not ideal in my opinion. However, as explained above field is not to be used in the update method. Then what can we use? Since we are traversing the fields of the fieldArray, field is the object we have but with messed up id property... I am quite confused. We should then use getValue potentially in a deeply nested array in the form, just to avoid overwriting of the id? What would you recommend?

edit:
to sum up the above and as far as I understand - update method becomes useless if you remove keyName and the data item in the array has id property. You cannot use the fieldArray update directly but have to resolve to getValues, setValue dynamically generating your form input name within nested structure and array index.

e.g. something along the lines setValue(`sizeDefinitions.${index}`, { ...getValues(`sizeDefinitions.${index}`), transformer: result });, where transformer is the only prop that changes.

[mateusdeitos-tiny]

Currently I faced the exact cenario described in your update example.

Another dev on my team pointed out in a PR that keyName will be removed and asked me to not use it but when I tried using the update method without keyName it messed up because i was overwriting the id prop of the object.

I think the keyName is a good solutions for those kind of cenarios

[Naught0]

I am dealing with something similar, but I think I understand the reason for the removal now.

const { fields, append, remove, replace } = useFieldArray(...etc) gives you the fields array.

fields[0].id will contain an automatically generated ID which should be used for the key prop of your component.

If you use watch to check the value of your form state, you would find that id is not present in the data unless it is part of the form OR you have set it yourself otherwise. This effectively makes keyName a non-issue because the id from hook-form is no longer polluting your form objects and can be thought of as "internal" to hook-form's state.

At least, that's what I'm banking on right now lol. Hopefully I'm not off base, and I'll find out for certain soon once I start interacting with my API.

Edit: I see this is a mostly redundant post, but it helped me step through the logic anyway

[Palmik]

I understand that RHF needs the id prop. But the current API (without keyName, especially) is confusing and error prone.

Assume you do something like:

type FormData = {
  foo: FieldModel[]
}

const form = useForm<FormData>({
  resolver: zodResolver(formDataSchema),
  defaultValues
});
const { fields } = useFieldArray({
  control: form.control,
  name: 'foo'
});

I suggest that the type of fields should be changed. Right now the type of fields is essentially FieldModel & {id: string}, where the id is supplied by RHF (and potentially overrides user's own id from the model).

One alternative, that would avoid all sorts of clashes and issues, is that fields would be {id: string; value: FieldModel}, or even just {id: string; } since I saw maintainers saying one should not be accessing their data through the fields array anyway, and use watch or getValues instead.

Let me know what you think.

[BrendanC23]

This makes the most sense to me. It seems like changing the type to { id: string; } would solve most of the confusion. It's currently unnecessarily complicated that fields.elem works for non-id values, but we need to use getValues to get the id. If we aren't supposed to be accessing the data through fields and getValues is the suggested way to access field data, then removing the form data from field and just having an id would greatly simplify things.

@bluebill1049 Can you share your thoughts?

[AdventureBear]

how would you use watch for nested forms? The only way i got it to work was by prop drilling and that's not convenient, and is error prone. Why shouldn't you access data through the fields array though? Isn't that what it is there for to hold form state? Sorry of my question is too newbie, just trying to get this monster form (that's not really all that complex) to work and keep working.

[BrendanC23]

I've run into instances where the fields data isn't reactive and doesn't trigger a re-render when the values change. The only way to accomplish that is using form.watch() or useWatch() (form.getValues() also won't trigger a re-render). This does lead to some prop-drilling of form, but that can be solved with Context and FormProvider if necessary.

If you just need a static object with field values, then you could call form.getValues().foo[index] and pass that to the child component.

[maikeriva]

Hi, I also recently found out RHF's use of the id field in arrays and the future deprecation of keyName.

I would like for it to either not be deprecated or have an alternative. Here's my use case.

I use RHF to collect data in a form with dynamic fields. The form data structure is:

type nestedItemsList = {
  id: string
  name: string
  items: {
    id: string
    name: string
    subItems: {
      id: string,
      name: string
    }[]
  }[]
}

The data is fed in a database which uses exactly the same data structure. Id fields are used internally as unique identifiers for the items and subitems, and are automatically assigned by the database.

When I need to update a nestedItemsList and add a new item, its id field is thus significant for the db: if undefined the item will be newly created, if not the corresponding item will be searched and updated.

To prevent RHF from meddling with id fields and breaking the db logic, I currently use keyName to force it to use another field. But what should I do when this feature gets removed? Is there another recommended and equally easy approach?

This is the only issue I have with this otherwise excellent library :)

[Naught0]

I think the wording and usage of the id prop and its deprecation is very confusing. I have the same exact use-case.

In the latest version of RHF, when the form is submitted or when you are watching for updates with watch or similar, you will actually always receive the expected ID from the DB (or undefined). The id property referenced by keyName only applies to the fields object which you are only using to render inputs -- i.e. the id prop does not pollute your data, but only the fields object which is used for rendering.

See my comment here:
https://github.com/orgs/react-hook-form/discussions/8935#discussioncomment-6995941

And another from a person involved with RHF Dev:
https://github.com/orgs/react-hook-form/discussions/8935#discussioncomment-4002113

I hope it helps.

[maikeriva]

I see, thanks for the extra info. But I still can't think of a convenient replacement solution for my case.

I prepared a barebones example. In this UI, form fields are edited through a disappearing modal, which lies in another section of the UI (for example, even outside the current form). The user thus has to click on an "edit" button to modify an item, which opens a modal with a modalForm initialized to the current item.
With keyName this approach works, as I can avoid field conflicts when initializing the modalForm. But how could I deal with it when it will be deprecated?

type Item = {
  id?: string
  name?: string
}

type ItemList = {
  id?: string
  name?: string
  items: Item[]
}

const Component = () => {

  const { register, control, handleSubmit } = useForm<ItemList>()
  const { fields, append, update, remove } = useFieldArray({
    control: control,
    name: `items`,
  })

  const [editIndex, setEditIndex] = useState<number | null>(null)
  const { register: modalRegister, handleSubmit: modalHandleSubmit, reset: modalReset } = useForm<Item>()

  return (<>
    <form onSubmit={handleSubmit((data) => console.log(data))}>
      <input type="text" {...register("name")} />
      <button type="button" onClick={() => append({})}>Add item</button>
      {fields.map((item, i) => (
        <div key={item.id}>
          <button type="button" onClick={() => remove(i)}>Remove item</button>
          <button type="button" onClick={() => {
            modalReset(item)
            setEditIndex(i)
          }}>Edit item</button>
        </div>
      ))}
      <button type="submit">Save</button>
    </form>
    {editIndex !== null &&
      <div>
        <input type="text" {...modalRegister("name")} />
        <button type="button" onClick={modalHandleSubmit((data) => update(editIndex, data))}>Save item</button>
      </div>
    }
  </>)
}

Link to codeSandbox: https://codesandbox.io/s/react-typescript-forked-mgyl2y

[Naught0]

Your console.log statement onSubmit should/will not have an id set other than the one provided in the data. The only thing RHF does is help you out with item.id via the fields array. data is entirely independent when using watch or getValue or handleSubmit. If you do not observe this to be true, then you're potentially using an old version of RHF

[codeto0516]

https://stackoverflow.com/questions/77289582/react-hook-form-usefieldarray-overwriting-my-own-id

[macr1408]

Just to clarify the previous workarounds (they weren't clear enough to me):

const { fields, append, remove } = useFieldArray({
    control,
    name: 'something',
  });
const form = useFormContext();
const realValues = form.getValues('myArrayField');

// ...

{fields.map((row, index) => (
  <tr key={row.id}>
    <td>
      <input
        type="text"
        defaultValue={realValues[index].id}
      />
    </td>
  </tr>
));}

[AdventureBear]

when i tried this I still got the generated uuid instead of my db id for the defaultValue example you have above

[AdventureBear]

I'm also using the keyName to solve a problem where I send a delete request from inside a modal form, and do an "optimistic update" using remove. it works well with keyName. The reason I do it this way is because the modal form overlays my main database object, and if I refresh the data, the modal will disappear and need to be reopened again.

What other ways are peope using to delete an array element and do an optimistic update?

[pauldmps]

I almost pulled my hairs off trying to debug for hours why my ids were not matching in the code when moving the existing logic from formik to react-hook-form. This is terrible design. The developer should be responsible for managing the ids, or at least make sure that id field is not overwritten if it already exists. Or don't remove the keyName prop from the hook in the next version.

[bombillazo]

Why is keyName being dropped in the first place?

[sstackus]

At least use a property name whose name clearly signals that it's used for internal purposes, like __id or $id.

Then lock it down:

Object.defineProperty(arrayItem, '__id', {
  value: 'uuid',
  enumerable: true, // avoid causing blackbox headaches
  writable: false,
  configurable: false,
})

---

You can't just mutate the data passed in and overwrite a property with zero regards.

How this made it into a release is beyond me.