Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

why would reordering be slow when passed index to key prop? #10102

Closed
pycraft114 opened this issue Jul 4, 2017 · 3 comments
Closed

why would reordering be slow when passed index to key prop? #10102

pycraft114 opened this issue Jul 4, 2017 · 3 comments

Comments

@pycraft114
Copy link

#8410

there is already a same question in this issue but havent been answered.
ps. i have already read the documentation , but as @bondarewicz said it is a bit indistinct

@gaearon
Copy link
Collaborator

gaearon commented Jul 4, 2017

It's not gonna be slow per se, but there's just not going to be reordering at all.

For example instead of moving 1, 2, 3 to 3, 2, 1 it would update 1 to be 3, and 3 to be 1. For deeper component hierarchies, these can be deeper (and potentially more expensive) updates. Keys are the only way React can know that something has moved rather than updated. This is not just important for performance, but also for correctness. In our example earlier local state of 1 would be preserved for 3, although conceptually these are different items. But if we used keys then local state would "move" together with the item.

Hope this helps!

@pycraft114
Copy link
Author

Thx for the answer. but can you give me an example why React knowing that something has moved rather than updated is important for performance?

@gaearon
Copy link
Collaborator

gaearon commented Jul 11, 2017

Because just moving a few trees around is usually cheaper than going "deep" into each tree and updating every single thing inside of it.

@gaearon gaearon closed this as completed Jul 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants