As React developers, we’ve all heard the mantra: “Don’t use array index as a key!” It’s repeated so often that it’s become an unquestionable rule for many. But like many rules in programming, the reality is more nuanced. Today, we’re going to explore situations where using an index as a key might not be the cardinal sin it’s often made out to be.

Understanding Keys, Reconciliation, and the Render-Commit Cycle

Before we dive into the controversy, let’s refresh our understanding of what keys do in React and how they fit into the bigger picture.

The Reconciliation Process

React’s reconciliation process is at the heart of its efficiency. When a component’s state or props change, React creates a new virtual DOM and compares it with the previous one. This comparison, or “diffing,” allows React to minimize actual DOM manipulations, which are costly in terms of performance.

The Render-Commit Cycle

1. Render Phase: React calls your components to figure out what should be on the screen. It creates a new virtual DOM based on the current state and props.
2. Reconciliation: React compares the new virtual DOM with the previous one, identifying what has changed.
3. Commit Phase: React applies the identified changes to the actual DOM.

The Role of Keys

Keys play a crucial role in the reconciliation process. They help React identify which items in a list have changed, been added, or been removed. A key is a special string attribute that you need to include when creating lists of elements.

What Exactly Do Keys Solve?

Keys solve the problem of efficient list updates. When you have a dynamic list (items can be added, removed, or reordered), keys help React track which specific items have changed.

Without keys (or with poorly chosen keys), React might unnecessarily recreate DOM elements that haven’t actually changed, leading to performance issues and potential bugs with component state.

The Case for Using Index as a Key

Now, let’s look at why using an index as a key isn’t always bad. Consider this scenario:

const NumberList = ({ numbers }) => {
  return (
    <ul>
      {numbers.map((number, index) => (
        <li key={index}>{number}</li>
      ))}
    </ul>
  );
};

In this example, using the index as a key is perfectly fine if:

1. The list is static (items are not added, removed, or reordered).
2. The items in the list have no ids (otherwise we could use the id instead of the index).
3. The list is never reordered or filtered.

Under these conditions, the index is stable and using it as a key won’t cause any issues.

The Real Problem: Unstable Keys

The issue isn’t really about using the index itself, but about using unstable keys. An index becomes problematic when it doesn’t consistently refer to the same item. This happens when:

• Items are added to or removed from the beginning or middle of the list.
• The list is reversed or sorted.

In these cases, the index of each item changes, leading React to misidentify components and potentially cause bugs or unnecessary re-renders.

Conclusion

While it’s generally a good practice to use unique and stable identifiers as keys, dogmatically avoiding index as a key in all situations is unnecessary. Understanding the reconciliation process and the purpose of keys allows you to make informed decisions about when using an index is acceptable or even preferable.

Remember, the key rule (pun intended) is stability. As long as your key consistently refers to the same item across re-renders, whether it’s an id, a unique attribute, or yes, sometimes even an index, you’re on the right track.

So next time you reach for that index as a key, don’t feel guilty — just make sure you understand the implications and that it’s the right tool for your specific use case.

P.S. You can find more information on React docs.

If you want to stay updated with the latest JavaScript and software development news, join my Telegram channel: TechSavvy: Frontend & Backend.