This course has been updated! We now recommend you take the Complete Intro to React, v8 course.
Transcript from the "Key Prop" Lesson
[00:00:00]
>> Brian Holt: Now let's go ahead and fix this error down here. So it has this key error. So for the most part it reacts pretty smart about the way it optimizes your code. And then using some interesting heuristics it can kind of figure out a bunch of interesting parts about it.
[00:00:17] But this particular case is one case that they kind of ask for your help to optimize your code.
>> Brian Holt: So imagine we had a sort on our different shows. So that we could sort by release date, we could sort by rating, views, anything like that. So we were taking the same bits of data and we are re-arranging it into different pieces.
[00:00:47] Well, all React sees is on one render, I saw that I had House of Cards, Daredevil, Orange is the New Black. I had all these different objects. And then on the re-render it sees all of these things have changed. It has no idea that these things are actually the same objects, but just in a different order.
[00:01:05] It has no handle, no way of knowing that. So what that actually means is it's just going to blow up everything and then re-render everything. Now this ends up being kind of a problem. Because like these are kind of simple components but emerges [INAUDIBLE] like deeply nested huge amounts of components, lots of different really bad things going on.
[00:01:25] Not really bad just really complex things. Destroying and re-rendering actually ends up being really, really expensive. If you have ephemeral data, it gets even worse. Then you have to make Ajax calls and things like that. So what React asks you to do, is it says, give me a key.
[00:01:44] That I could check, just do a shallow check is key equal to key, yes. But now they're out of order, I'm just going to take this and move it down here. And so it doesn't have to recreate all of that DOM for you. Does that make sense of why key exists?
[00:01:58]
>> Brian Holt: So if we go here to ShowCard and we give it a key. We have to give it some unique identifier that's always going to be the same, right? Just some sort of ID. So that each one of them has an imdbID, which we can guarantee is unique for each one of them.
[00:02:15] You could give it the title if you didn't have an imdb. But in this particular this is an easy one for it to identify. So that's a good one to use, so we'll use that one. So now if we save that and refresh, now that warning's gone.
>> Audience 1: So you mentioned that for the key it has to be unique?
[00:02:39] So in this case, it would be a bad idea to use the index parameter on a map. Because that might change if that data changed at all.
>> Brian Holt: So why that doesn't work super well is if I have Daredevil at number one, right? And then I resort it and Daredevil is number five, that equality check it's not gonna be the same, right?
[00:03:03] Furthermore it's gonna be bad because now there's gonna be something else in number ones position. So there's no mapping from the index to the object. So that's a poor key to use.
>> Audience 1: Okay, first question is, how long until the next break? Someone has to leave but they want to wait till the next break.
[00:03:24]
>> Brian Holt: [LAUGH] Give me 10 minutes.
>> Audience 1: 10 minutes, okay great. Next question from Anton, this is a little complicated so hopefully I'll get this. Is it a good idea to return the ShowCard component in one line by using the arrow functions feature?
>> Audience 1: The short way of doing that?
[00:03:41]
>> Brian Holt: Yeah, so what our friend is referring to, is you can actually write this like this. Oops.
>> Brian Holt: Is this okay? It's a little dense for my taste. But if you don't put curly braces with arrow functions, there is an implicit return. So in this particular case, there's an implicit return of show card as a component.
[00:04:14] Is that okay? Like I said, I feel it's just a little dense for my taste, but it works. My mantra is always air on the side of readability and maintainability. Because I wanna be able to look at this and instantly understand what's going on. I don't have to unpack this in my mind.
[00:04:31] So I like arrow functions and implicit returns. But just maybe not in this case cuz I feel like this is too dense for me.
>> Audience 1: Okay, they are asking if you could recap the issue with key again please.
>> Brian Holt: Yeah. So basically if we start rearranging our ShowCards, we want React to very quickly be able to tell this object and this object are the same.
[00:04:58] Despite the fact that before this was index zero and next it was index ten, right? We want React to have a very quick way to identify these two are the same object. So we basically say here's a unique identifier. If you compare this and they're the same, I guarantee you this is the same object.
[00:05:15] And so React is then able to do quick comparisons to say, keep this DOM or don't keep this DOM. That's the gist.
>> Audience 1: And the issue about using just the index as opposed to an actual ID?
>> Brian Holt: The reason you want to do that is that if you start resorting things, their index is not going to correlate.
[00:05:38] So if I have
>> Brian Holt: 'a', 'b', 'c', right, and all of a sudden I want to search. So this is going to be index zero. This is going to be index one and this is going to be index two. On the next iteration I say hey sort by reverse alphabetical order.
[00:06:00] This is going to be c, this is going to be b, and this is going to be a.
>> Brian Holt: And those indexes still apply, right? On iteration one, a is zero, right? On the second iteration, c is zero. These are not the same strings. I need the key to always correspond to the same object.
[00:06:22] So I need this a and this a to be the same one. So that's why the key needs to be, correspond to the same object always.
>> Audience 1: Francois is having an issue that their browser will not refresh if they are having any linter errors.
>> Brian Holt: Their browser won't refresh if there's having any linter errors?
[00:06:44] The browser should refresh if there's linter errors but if there's web pack errors, Webpack won't build. And if web pack won't build then you don't get any new code. You're stuck with the old code from the last time you successively built. So my intuition tells me that that's not a linter error, that's a Webpack error.
[00:07:02] Which means this is probably a syntax error or something that basically Webpack doesn't know how to build anymore.
>> Audience 1: Yeah. They are saying they're seeing a linter error in the browser.
>> Brian Holt: That might happen.
>> Brian Holt: All right, so
>> Brian Holt: I'm not, but I know it has the ability to output those to the console.
[00:07:33] Which is a nice feature cuz then you can see those errors in real time.
>> Audience 1: Someone else is also saying they got React prop types ES lint error.
>> Brian Holt: Yeah I know, I'm gonna fix those.
>> Audience 1: Okay.
>> Brian Holt: Let me go ahead and push up a new branch though.
[00:07:57]
>> Audience 1: Donarte is asking if they should call dumb components from inside other dumb components. Or use a smart component to put everything together?
>> Brian Holt: I don't know if you can make that generalization. I'm assuming when they say smart or dumb, that they're thinking stateless functional components versus reacts, create class or something like that.
[00:08:21] My rule of thumb. And again I'll cover this tomorrow. Is use stateless functional components when they fit and when they don't, use the other one you prefer.