React: Is it possible to use ES6 Symbol as component key?

[coodoo]

Last time I tried it with 0.14 this still won't work, any reason why? Thanks.

[sophiebits]

Partly just because no one asked for it. We won't do this for 0.14 but it's possible we could for the next release.

[coodoo]

Perfect, very looking forward to it!

[jimfb]

@spicyj I'm not sure if this is a good idea, unless we plan to drop keys from SSR, because there is no way to serialize the symbols. We want components to be as isomorphic as possible, and this would break that for no good reason.

[sophiebits]

@jimfb keys don't appear in the DOM so it should be fine.

[jimfb]

@spicyj They don't? Aren't they part of the react-data-id when doing SSR?

[sophiebits]

Not any more.

[sophiebits]

We do still use them internally though as strings I guess.

[jimfb]

Well :hankey:, that's :fire:

[gaearon]

Closing as I'm not aware of a compelling reason to allow it. If you see a good reason please send a PR and let's discuss this.

[MiLeung]

Late to the party, but...

At first thought, Symbols would just add unnecessary complexity. But it would be nice to use Symbols rather than Math.random or shortid for component keys

[quanganhtran]

Flattened composite keys for example?
For example if the key could be parentName1$childName1 we might end up with

const data = [
  { name: 'abc$def', children: ['gh', 'x'] },
  { name: 'abc', children: ['def$gh', 'y'] }
]

We will have key collision at abc$def$gh. Sure the example is very specific so I cannot argue how common is this use case, but if the names come from the user then it might happen no matter what delimiter you use
So if not symbol then at least some kind of reference

[Sleepful]

I don't understand why this was closed? The compelling case is having an ES6 way of defining random keys without having to use a third-party library. Not all rendered arrays have an identifying property and we are forced to use things like UUID because using the index position leads to bugs. StackOverflow related answer.