Check out a free preview of the full Complete Intro to React, v3 (feat. Redux, Router & Flow) course:
The "Key Prop" Lesson is part of the full, Complete Intro to React, v3 (feat. Redux, Router & Flow) course featured in this preview video. Here's what you'd learn in this lesson:

When components are generated from a list of data, React needs a method for keeping track of each individual component. The “key” property allows developers to specify a key value for each component. Typically the primary key or some other unique identifier from the data would be used for the key property.

Get Unlimited Access Now

Transcript from the "Key Prop" Lesson

[00:00:00]
>> Brian Holt: Now if we come back here, everything should be working, but we're getting this error down here in the console which is each item, each child in an array should have a unique key property. So you should be seeing that right now cuz we have not fixed it.

[00:00:14] Let's talk about that.
>> Brian Holt: So imagine we had a sort ability on here that we could sort shows by title ascending, descending, by when it was released sort by all these different things, right? Well, what would be happening is we'd have this array of components and we'd be like changing the order of them, right?

[00:00:34] And each one of these components has a somewhat nested style of components, there's components, within components, within components, right? Well right now the way it works is React is going to check is this array as the same as the one that was there. And it's gonna say no, and then it's gonna blow everything away and totally rerender everything.

[00:00:59] Now that should like set off some warning bells in your head because that's really inefficient, right? What it could be doing is just reorganizing them right? Because that's all we're doing so it could keep all of that dom structure all those dom nodes and just move them around.

[00:01:14] And these aren't particularly complicated components, right? But imagine if they were deeply nested components that had like, D3 charts, and SVGs, and all that kind of crazy stuff on there. That could get really expensive, really fast, especially if you have like 100 nodes. So now I'm painting like worst case scenario for you but, hopefully I'm demonstrating you to the problem that could exist here.

[00:01:37] So the way that you can sidestep this, if we go back to search.jsx, we can give basically reacts like hey, here's a handle that you can hold onto, right? Something really fast that you can compare to see if something changed, and if the order of things changed, right?

[00:01:54] So I can say, key and I can say key equal show dot, something that is unique about it. That's several pieces of information that are unique about it, but the most obvious one is the imdbID, right? Typically it´s gonna be some sort of identifier like that, but I mean it like, maybe it's like your users table and you can use the email as the key, right?

[00:02:19] The only thing that's required here is unique for that particular objects. And a big no, no which a lot of people are tempted to do is just say index right here, right? And then use index here, but what did that bias? Literally nothing, right? Because if anything get sorted out of order then the index is gonna change and it's gonna re-render anyway, right?

[00:02:41] So don't use index that way, unless that's literally the only thing that changes.
>> Brian Holt: So in this case, we're gonna use imdbID. That way, let's say if I move Atlanta from the first one to the last one, it can just say, okay, this imdbID is the same. I'm just gonna take this one and plop it down here.

[00:03:02] Make sense?
>> Brian Holt: Cool.
>> Brian Holt: So, now we should be able to go back over here and everything is all good.