{"id":3540,"date":"2021-07-24T08:53:39","date_gmt":"2021-07-24T08:53:39","guid":{"rendered":"http:\/\/the-codest.localhost\/blog\/react-keys-yes-you-need-them-but-why-exactly\/"},"modified":"2026-04-27T10:16:39","modified_gmt":"2026-04-27T10:16:39","slug":"react-keys-yes-you-need-them-but-why-exactly","status":"publish","type":"post","link":"https:\/\/thecodest.co\/en\/blog\/react-keys-yes-you-need-them-but-why-exactly\/","title":{"rendered":"React Keys, Yes! You Need Them, but Why Exactly?"},"content":{"rendered":"

There is also one more thing you need to remember about and that is the React<\/a> Key<\/strong> attribute, each element of the rendered list must have it. This concept is one of the first things every front-end developer<\/a> learns about React<\/strong> at the start of their journey. Now let\u2019s dig a little bit deeper to explore why this is the case, and when we can take some shortcuts.<\/p>\n

Why do we need this key attribute?<\/h2>\n

The simplest answer here would be \u201cto optimize re-renders\u201d, but the more complete one has to at least mention the concept of React Reconciliation<\/strong>. This is the process of figuring out how to update the UI in the most efficient way. To do that fast, React<\/strong> has to decide which parts of the tree of elements need to be updated and which do not. The thing is there might be a lot of elements in the DOM and comparing each of them in deciding which one should be updated is pretty expensive. To optimize this, React<\/strong> implements the diffing algorithm which is based on two assumptions:<\/p>\n

    \n
  1. Two different types of elements will never be the same \u2013 so re-render those.<\/li>\n
  2. Developers can manually help optimize that process via key attributes, so the elements, even if their order has changed, can be localized and compared faster.<\/li>\n<\/ol>\n

    Based on that, we can conclude that each React key<\/strong> should also be unique (within the list of elements, not globally), and stable (should not change). But what could happen when they are not tat?<\/p>\n

    Uniqueness, stability and array index<\/h2>\n

    As we mentioned before, React keys<\/strong> should be stable and unique. The easiest way to achieve this is to use a unique ID (for example from a database) and pass it to each element when mapping an array, easy. But what about situations when we don\u2019t have an ID, a name or other unique identifiers to pass to each element? Well, if we don\u2019t pass anything as a key, React<\/strong> will take the current array index by default (since it is unique within that list) to handle it for us<\/a>, but it will also give us a nice error message in the console:<\/p>\n

    \"\"<\/p>\n

    Why is that the case? The answer is that the array index is not stable. If the order of the elements changes, each of the keys will change and we have a problem. If React<\/strong> encounters a situation where the order in a list of elements was changed, it will still try to compare them by the keys, that means that every comparison will end up in re-building a component and, as a result, the whole list will be rebuilt from scratch. In addition to that, we can encounter some unexpected problems, like component state updates for elements like uncontrolled inputs and other magical hard-to-debug problems.<\/p>\n

    Exceptions<\/h2>\n

    Let\u2019s get back to the array index. If using it as a React key<\/strong> can be so problematic, why React<\/strong> will use it by default? Is there any use-case where it\u2019s okay to do so? The answer is yes, the use-case for that is static lists. If you\u2019re sure that a list you\u2019re rendering will never change its order, it’s safe to use array index, but remember, if you have any unique identifiers, it’s still better to use them instead. You can also notice that passing indexes as keys will make the React<\/strong> error message disappear, while simultaneously triggering some of the external linters to display an error or warning. This is due to the fact that the explicit usage of indexes as keys is considered a bad practice and some linters might treat it as an error, while React<\/strong> itself considers it as a \u201cthe developers know what they are doing\u201d situation \u2013 so don\u2019t do that unless you\u2019re really know what you\u2019re doing.\u00a0 A few examples of when it can be okay to use that exception would be a dropdown with a static list of buttons or displaying a list of elements with your company address information.<\/p>\n

    An alternative to a dataset-based key<\/h2>\n

    Let\u2019s say that none of the above is an option for us. For example, we have to display a list of elements based on the array of strings which can be duplicated, but it can also be reordered. In this case, we cannot use any of the strings because they are not unique (this can cause some magical bugs, too), and the array index is not good enough because we will change the order of elements. The last thing we can rely on in situations like this is the use of some external identifiers. Remember, it has to be stable so we can\u2019t just go for Math.random(). There are some NPM packages that we can use in such cases, for example the \u201cuuid\u201d<\/a> package. Tools like that can help us keep our list keys stable and unique, even when we cannot find proper identifiers within our data<\/a> set. We should consider using database ID and array index (if possible) first, to minimize the number of packages used by our project<\/a>.<\/p>\n

    To wrap it up<\/h2>\n