Item — HN Reader

Regarding the usage of `crypto.randomUUID()` to generate unique `key` properties for list items, such a technique should only be necessary if the items don’t come with unique and stable ids on their own. This is the case for the example in the article, but in my experience, list items often do have some differentiator on their own, which you can either use directly, or otherwise derive for that purpose. If that’s the case, this is what I usually would prefer by default.

One other aspect that I find important to understand about the `key` property is that it only has to be unique among its direct siblings, but it doesn’t have to be unique globally.

8 comments

Right, I'm not sure the author understands key either. It's an optimization to help React identify insertion / removal / reordering of array items between re-render. https://beta.reactjs.org/learn/rendering-lists#where-to-get-...

Giving every item a new key on every update does not help with that - in fact it is likely strictly worse than just using index since it will cause every item to re-mount every update https://beta.reactjs.org/learn/preserving-and-resetting-stat... which is unlikely to be what you want.

Its not an optimisation, its about state management.

React can’t see the difference between a reorder and remove&insert. When reordering items the state should be moved as well; when removing and inserting a new item, state should reset.

Using an array index is equivalent to silencing the error

Not necessarily.

It depends on what your data source is. If it’s a stable sorted list that only ever gets appended at the end, you can use the index.

At the end of the day, there is no hard fast rule for the key. You have to know what your data source is.

You have to know what you’re doing.

> Giving every item a new key on every update does not help with that

fwiw the author specifies says not to do this. The advice is to generate a unique ID when items are created, not when they’re rendered.

I was going to reply the same thing. I do have a problem with the author presenting that as a default solution instead of a workaround if the item doesn't have a unique identifier, which I have found to be uncommon.

> such a technique should only be necessary if the items don’t come with unique and stable ids on their own.

FWIW, these tips are also covered in his React course and he makes it clear in the course that this key generation technique should only be done when items don't have something better to use as the key. I think the blog post is just missing that context.

From the article: "[The crypto module is] available in all major browsers. It has nothing to do with cryptocurrencies."

Funny, but sorry state of affairs: we need a new word for cryptography [1]:: mysticography [2]? "About 1 results" in Google Search, that's a first.

[1] https://www.etymonline.com/search?q=cryptography

[2] https://en.wiktionary.org/wiki/%CE%BC%CF%85%CF%83%CF%84%CE%B...

You're better off not using a key than using a random one (unless the random key is kept stable accross re-renders)

Even when not optimal, it’s good advice for the Intended audience “still pretty early in their journey”

> crypto.randomUUID is a method built into the browser (it's not a third-party package). It's available in all major browsers. It has nothing to do with cryptocurrencies

Yeah, and even lacking appropriate IDs, hashing the object can often (but not always) be more appropriate than a random ID.

So what's the problem with using index then?

If the items can be re-ordered (like prioritizing todos in a todo list) then items' keys will change when they should be stable.

If desperate use the index supplied with map, if the order is stable enough.