Enjoy free content straight from your inbox 💌
00:00
Based on the previous lessons, now that we understand the fundamentals of loops in React and the concept of pure components in this lesson, we will take a deep look at the value of providing unique and stable keys for React loops. So let's go to demonstrate the impact of keys in loops with React. Consider a simple application where we have a list of messages maintained with you state. Next we have a utility function that allows us to remove a message from a particular index. Within the messages array, we render out the messages into a simple diff that contains a span displaying the message value
00:34
and a button called remove that is wired to remove the message for this index. Notice that at this point, even though we are not using a key for the root dev within the loop, we can successfully remove any individual item and the application seems to work perfectly fine. However, this does not work when components have their own internal state. That is components which are MPO. Let's demonstrate a simple component that comes with React. That is stateful is the input element with the default value. The way this works is
01:05
that the component only reads the default value once, and if the component ever gets re rendered, the default value is not updated for the input element. This essentially makes the default value a set one's internal state for the input element. Now, if we remove the third last element, never gonna make you cry. You can see that our application no longer functions the way we would expect, and that particular lyric still hangs around to further drive this point home. If you were to replace default value with value to turn this input into a completely controlled and pure component, this error will go away.
01:39
If you provide the value proper the input component, whenever the component gets rear-ended, the input element will copy over the value. So now whichever lyric will remove is the one that actually gets removed from the screen. And this is the same successful behavior that we saw when we were using another built-in pure component, which is a simple span. You might think that using an index as a key would get rid of this error, but that actually doesn't work if we have impure components to demonstrate that, let's go back to the impure default value version of the input component and now actually provide the key pointing
02:14
to the current index for the root diviv. And now you might think that the application would behave the way you would expect. That is the lyric that you click on is the one that gets removed, but that is not the case. Now the reason why this is happening, just in case it is not obvious, is that when we are removing a particular index, for example, the element at index three and the application re-render, there is still an element at index three. Only the last key goes missing as far as react is concerned. And therefore that is the component that we do not see in the next re-render.
02:48
Now, if the components were pure, we would not notice this because the components would simply accept the new props and re-render with the new value. The proper way to provide keys in react, especially When we have stateful components, is to make sure that you use the key that uniquely identifies an individual item. Fortunately, for our particular list of messages, each message comes with a unique id and if we wire the key to message id, and even though we are using stateful default value version of the input, when we click remove on a particular lyric, that is the lyric that gets removed.
03:23
This is because now react can reliably diff which particular message got removed. Now, unique keys are actually required for impure components, but they even recommended for pure components for performance reasons. That's demonstrate. So we go back to our original example of using a pure span, but instead of using span, we will create our own custom component, which will be pure using reactor memo. And this will allow us to log to the console whenever this component gets rendered. So within the messages array, we render out our lytic component passing in message value. Notice that right now we are using the index as key, which
04:01
as we know is going to be fine as long as we have pure components. And indeed as we interact with the application, the correct lytic gets removed. But what might surprise you is the performance impact of using the index as key. Let's reload the application with the developer tools console open. We get initial six renders for the six lyrics, but when we remove the third last element, we would expect no additional renders. However, we see two additional renders on the console. This is because react is essentially same as before, remove the last element
04:35
because the last key has gone missing and the other two components have simply received the new props and have successfully re rendered. For the user, it looks fine, but in terms of performance, we just rendered two components that we didn't need to, and the impact will be greater if we remove something higher up in the index. For example, if we remove the second element, right now we get three additional re-render. Now let's repeat the process, but this time with the unique key provided by message id, we still get the six initial render, but as we remove an individual lyric, only
05:09
that particular lyric needs to go away and the rest of the lyrics do not need to be re rendered. I'll wrap things up there and to recap. If you have stateful components, then you definitely need to provide unique stable keys. But if you have pure component, then it is okay to use index indexes keys. However, even in that case, it is recommended that you provide unique stable keys for performance reasons. Thank you for joining me and I will see you in the next one.