Skip to content

Component keys and array index #8410

Closed
Closed

Description

@bondarewicz

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.

and from here:

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?

Activity

  1. syranide commented on Nov 24, 2016

    @syranide
    Contributor

    @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.

  2. gaearon commented on Nov 24, 2016

    @gaearon
    Collaborator
  3. bondarewicz commented on Nov 24, 2016

    @bondarewicz
    Author

    @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.

  4. gaearon commented on Nov 24, 2016

    @gaearon
    Collaborator

    @bondarewicz Would you like to work on this? Since you just learned about it, you have a fresh mind necessary to explain it well.

  5. laumair commented on Nov 27, 2016

    @laumair

    @gaearon Can I pick this up?

  6. gaearon commented on Nov 28, 2016

    @gaearon
    Collaborator

    Sure.

  7. bondarewicz commented on Nov 29, 2016

    @bondarewicz
    Author

    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 :)

  8. laumair commented on Nov 29, 2016

    @laumair

    @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.

  9. bvaughn commented on Oct 8, 2017

    @bvaughn
    Contributor

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions