You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is just a question, I hope someone can provide more information about the following statements from here:
We don't recommend using indexes for keys if the items can reorder, as that would be slow. You may read an in-depth explanation about why keys are necessary if you're interested.
As a last resort, you can pass item's index in the array as a key. This can work well if the items are never reordered, but reorders will be slow.
Can anyone provide some further explanation / references / links / docs on this subject?
What number of items are we talking about which rendering be slow on sort?
@bondarewicz I would say "slow" is a clumsy explanation. Keying allows component instances to be correctly associated between renders, correctly retaining state and rendered DOM. If you key it with say the numerical index in an array and then reorder the array, not only will the rendered DOM need to be partially re-rendered (rather than simply moved), the component state will also have been mixed up which can be a serious issue. This also affects focus, input undo history, etc.
So in short, unless you know what you're doing and you have very good reason to then you should always key dynamic children with something that uniquely identifies the source, i.e. some kind of ID.
@gaearon thanks, I already went through those links and IMHO they do not clearly (to me at least)
communicate the information that keys are about the identity of the items, further more I don't think they explain well enough why using an index of an array can potentially be an issue (maybe some kind of an example would convey the message better?)
@syranide thanks I found your explanation about the component state to be giving a bit more of a hint about what you might expect , I also found the following fiddle (original source) and comment
I think what's missing is an actual example or/and further explanation behind performance issues / drawbacks potentially related to keys.
@bondarewicz I haven't really started working on this atm, been stuck with some stuff. I will probably start on this tomorrow but by all means if you want to work on this just let me know here 👍
Otherwise, I'd be happy to ping you when I submit a PR for this.
The documentation and source code for reactjs.org now lives in a different repository: reactjs/reactjs.org. (For more info on why we made this move, see issue #11075.)
I created an issue in the new repo already that I think is related to this, so let's just continue the discussion there? The new issue is: reactjs/react.dev/issues/79
Activity
syranide commentedon Nov 24, 2016
@bondarewicz I would say "slow" is a clumsy explanation. Keying allows component instances to be correctly associated between renders, correctly retaining state and rendered DOM. If you key it with say the numerical index in an array and then reorder the array, not only will the rendered DOM need to be partially re-rendered (rather than simply moved), the component state will also have been mixed up which can be a serious issue. This also affects focus, input undo history, etc.
So in short, unless you know what you're doing and you have very good reason to then you should always key dynamic children with something that uniquely identifies the source, i.e. some kind of ID.
gaearon commentedon Nov 24, 2016
Does this help?
https://facebook.github.io/react/docs/reconciliation.html#recursing-on-children
https://facebook.github.io/react/docs/reconciliation.html#keys
Should we link to those chapters more prominently?
bondarewicz commentedon Nov 24, 2016
@gaearon thanks, I already went through those links and IMHO they do not clearly (to me at least)
communicate the information that keys are about the identity of the items, further more I don't think they explain well enough why using an index of an array can potentially be an issue (maybe some kind of an example would convey the message better?)
@syranide thanks I found your explanation about the component state to be giving a bit more of a hint about what you might expect , I also found the following fiddle (original source) and comment
I think what's missing is an actual example or/and further explanation behind performance issues / drawbacks potentially related to keys.
gaearon commentedon Nov 24, 2016
@bondarewicz Would you like to work on this? Since you just learned about it, you have a fresh mind necessary to explain it well.
laumair commentedon Nov 27, 2016
@gaearon Can I pick this up?
gaearon commentedon Nov 28, 2016
Sure.
bondarewicz commentedon Nov 29, 2016
sorry fro delayed response, since @laumair already picked it up; if you would like me to have a peek at your PR just ping me :)
laumair commentedon Nov 29, 2016
@bondarewicz I haven't really started working on this atm, been stuck with some stuff. I will probably start on this tomorrow but by all means if you want to work on this just let me know here 👍
Otherwise, I'd be happy to ping you when I submit a PR for this.
bvaughn commentedon Oct 8, 2017
Thank you for filing this issue! 😄
The documentation and source code for reactjs.org now lives in a different repository: reactjs/reactjs.org. (For more info on why we made this move, see issue #11075.)
I created an issue in the new repo already that I think is related to this, so let's just continue the discussion there? The new issue is: reactjs/react.dev/issues/79