Consider providing a default key for dynamic children

[frosas]

Because many times performance is not an issue, I find myself doing things like this:

React.DOM.ul(null, items.map(function(item) {
  return React.DOM.li({key: Math.random()}, item.property)
})

Would make sense to have something like this by default?

[zpao]

I understand where you're coming from, but please don't ever do what you have there. We made this mistake in one of our examples for a while and it's just really bad. By doing this, you'll actually end up recreating all of your nodes on every render because the key will be different. While it might not hurt you today, it will one day.

A couple other points:

• key is not really about performance, it's more about identity (which in turn leads to better performance). randomly assigned and changing values are not identity
• We can't realistically provide keys without knowing how your data is modeled. I would suggest maybe using some sort of hashing function if you don't have ids
• We already have internal keys when we use arrays, but they are the index in the array. When you insert a new element, those keys are wrong.

Now that said, they key warning can be pretty annoying. If it's driving people to end up with solutions like you have here, then we should probably spend some time thinking of a better way to do this.

tl;dr: "no"

[frosas]

I'm not sure to understand what implications it has to not use a single key per children, apart from the degraded performance of course. Is it something related to future plans maybe?

I agree a random key is the worst key one can use, but it's still better than no key at all, and one can always spend time on a better solution when performance becomes an issue.

It's understandable you are trying to avoid this approach, I definitely do when working with entities but when the children components are based on value objects the alternatives doesn't seem much appealing (here I'm basically thinking about keeping a map of objects and their "ad hoc synthetic" keys).

[frosas]

Ok, I think I've got the identity point.

I could only think of the case of some state in a DOM element previously linked to another component being "inherited" when another similar component reuses the same element. My approach solved it well enough (IMHO).

But now I see that, if the key is not only unique but persistent over time, the opposite case still applies: every time the component is rendered all the state not being handled by React simply disappears!

Hopefully in the future it will be easier to handle these cases with ES6 WeakMaps.

[sophiebits]

I agree a random key is the worst key one can use, but it's still better than no key at all.

If no keys are provided, React uses the index in the array which is almost always better than a random key.

[suhaotian]

@spicyj Yeah,I agree

[noscripter]

#1342 (comment)

We already have internal keys when we use arrays, but they are the index in the array. When you insert a new element, those keys are wrong.

This point is important to note, because it's a common problem to be encountered when writing list components.