In the last section we got our list of images to display.
But if you look at your terminal or your counsel in the browser you might notice we got a little warning
here.
Now this is a warning not a error per se.
So our application is going to work just fine.
But re-act would really prefer if we did something a little bit differently inside of our image list
file a look at the wording here says Each child should have a unique key prob..
And then also tells us that the source of this warning is the image list component.
In this section let's talk about what this key thing is and why we are supposed to use one or to find
one whenever we are building a list of components.
All right so quick example here let's forget about getting a list of images right now.
Let's imagine that we instead have a list of to do items or things that we have to do throughout the
day.
So let's imagine that each to do looks like what you see right here it is a object with a I.D. and a
task.
So take out the trash wash the car and walk the cat walk the dog let's be a little bit better.
There that's better.
OK.
So in theory we might want to show this list of to do to the user so we might want to render it as a
list and say take out the trash wash the dog wash the car walk the dog inside of a collection of device.
So let's now imagine that we've rendered this list right here and we've shown it in the dome and it's
visible on the screen.
And then maybe at some point in time our user comes along and decides that they need to add one more
to do item.
They want to put on a new to do here.
And they want to have some new task for it.
So we would be in this type of situation.
We've now added on a new task of mow the lawn when we update our list of items right here.
Let's imagine that we then tell react to read render our application.
So in memory we're kind of behind the scenes reactant going to take this list of to do items that we
have now rendered as GSX and it takes this list right here a div for each item and then it looks at
what is currently present in the DOM know what re-act is going to try to do what it wants to do it wants
to notice or wants to see that hey I've got a dish here that has to say take out the trash and it turns
out there's already div inside the dam that says Take out the trash re-act wants to say oh this div
is already in the dorm.
I don't need to render it or I don't need to insert anything for that item it then will go onto the
next item and it wants to say it wants to have the ability Oh wash the car well that div is already
in the dorm.
I don't need to render that.
And then the same thing for Walk the dog as well.
And so finally reacts would say OK let's see mow the lawn.
Well I don't see that represented in the dome right now so I guess this is the one location where I
actually do have to do an update and appends some new element to the door.
Like I said that is what re-act wants to do in order to allow rock to actually do that.
We have to add in this thing called a key prop to each element in the list of items that we are rendering.
So let's take a look at what that would look like.
All right so same list here but now you'll notice that every element has a key prop this key prop right
here has reused the ID of each of these two items.
We'll talk about why we did that in just a second.
But right now let's kind of take a get a better look at what would happen when re-act tries to take
this new list and stick it into the dump.
It's now in this case re-act would say OK let's see div with Q1.
Let's look at all the device here and try to find one with key one.
Oh there it is.
Reacts well then compare the contents right here with that.
And I'll say OK.
They are identical.
Fantastic.
Well then move onto div with Key to it look through the list find a do with Geetu and then do that same
comparison and the same thing with Keith 3.
And then it gets down to four and it says I see no element with key 4.
Ok I guess I will put this into the door.
So that's the purpose of the key.
It is purely a performance consideration and it's going to help re-act render lists or updates to lists
to be more precise more performant Lee than if you left off that key entirely.
So it's in your best interest to make sure that you include a key on every element that you render as
part of a list.
That's the important part.
We cannot do it for every element only for lists of elements.
OK so now why did we use the ID of these items for the key when they actually got rendered.
Well as you might imagine the idea here is that every one of these items is going to eventually be represented
as a div or maybe a lie or a span or whatever type of element we decide to use whenever we use a key.
We try to use a key property or a value for this key that corresponds to one distinct element in the
array of items that we are iterating over or trying to render out into the DOM.
In practice that usually ends up being very convenient to just use a id property if we have one for
these items that we are trying to iterate over.
Now it turns out that in a vast majority of cases if you're not using like fake or dummy data or something
like that and particularly if you are fetching data from some outside API it turns out that just about
every time you get a list of items that you want to show them as a list you will very frequently have
an id property because this id property uniquely identifies this record.
It is perfectly suited to serve as a key when we are rounding our list as well.
OK so that's the idea.
Let's take a quick pause right here.
When we come back the next section we're going to add in some keys to these images that we are rendering
and hopefully we're going to get that error message to go away.