In [React](/courses/reactjs), a `key` is a special attribute used when rendering a list of elements. It helps [React](/courses/reactjs) identify **which item is which between renders**. For example: ```jsx const users = [ { id: 1, name: "Asif" }, { id: 2, name: "Rahul" }, { id: 3, name: "Aman" } ]; function UserList() { return (

{user.name}

); } ``` Here: ```jsx key={user.id} ``` gives every list item a stable identity. This is important because React needs to determine what changed when the list is updated. --- ## What Problem Do Keys Solve? Suppose React renders this list: ```text Asif Rahul Aman ``` Later, a new user is inserted at the beginning: ```text John Asif Rahul Aman ``` React needs to answer questions like: ```text Which item is new? Which existing items stayed the same? Which items were moved? Which items were removed? ``` Keys help React answer these questions efficiently. With stable keys: ```text 1 → Asif 2 → Rahul 3 → Aman ``` and after adding John: ```text 4 → John 1 → Asif 2 → Rahul 3 → Aman ``` React can understand: ```text key 4 is new key 1 still represents Asif key 2 still represents Rahul key 3 still represents Aman ``` This allows React to preserve the identity of existing components. --- ## How React Uses Keys During Reconciliation React uses a process called **reconciliation** to compare the previous UI tree with the new one. Imagine the previous render: ```jsx [ , , ] ``` Then the next render becomes: ```jsx [ , , , ] ``` React compares the keys and can see: ```text 4 → new component 1 → existing component 2 → existing component 3 → existing component ``` So React can preserve the existing components instead of treating them as completely different items. --- ## Why Are Keys Important for Component State? Keys are not only about performance. They are also important for preserving the **correct component state**. Consider a list of editable users: ```jsx function UserList({ users }) { return (

{users.map(user => ( ))}

); } ``` And: ```jsx function UserRow({ user }) { const [text, setText] = React.useState(user.name); return ( setText(e.target.value)} /> ); } ``` Each `UserRow` has its own state. React uses the key to associate that state with the correct user. Conceptually: ```text key 101 ↓ User: Asif State: "Asif" key 102 ↓ User: Rahul State: "Rahul" ``` If the list order changes, stable keys allow React to keep the correct state attached to the correct user. --- ## Why Is an Array Index Often a Poor Key? A common mistake is using the array index: ```jsx users.map((user, index) => ( )) ``` At first, this appears to work. But an index represents an item's **position in the array**, not the identity of the item itself. That becomes a problem when items are: * Added * Removed * Reordered * Sorted * Filtered --- ## Example: The Problem With Array Index Keys Suppose we have: ```js const users = [ { id: 101, name: "Asif" }, { id: 102, name: "Rahul" }, { id: 103, name: "Aman" } ]; ``` Using array indexes as keys produces: ```text key 0 → Asif key 1 → Rahul key 2 → Aman ``` Now remove Asif. The new list becomes: ```js [ { id: 102, name: "Rahul" }, { id: 103, name: "Aman" } ] ``` React now sees: ```text key 0 → Rahul key 1 → Aman ``` But previously: ```text key 0 → Asif key 1 → Rahul ``` The meaning of the keys has changed. React may assume: ```text key 0 is still the same component key 1 is still the same component ``` even though the actual data associated with those positions has changed. This can lead to incorrect state being reused. --- ## A Simple State Bug Example Consider: ```jsx function TodoItem({ todo }) { const [completed, setCompleted] = React.useState(false); return (

setCompleted(!completed)} /> {todo.title}

); } ``` Now render it like this: ```jsx function TodoList({ todos }) { return ( <> {todos.map((todo, index) => ( ))} ); } ``` Suppose the list is: ```text 0 → Learn React 1 → Learn Next.js 2 → Learn Node.js ``` You check: ```text Learn Next.js ``` So React stores state approximately like: ```text key 0 → unchecked key 1 → checked key 2 → unchecked ``` Now suppose you delete the first item: ```text Learn React ``` The array becomes: ```text 0 → Learn Next.js 1 → Learn Node.js ``` Notice what happened. Previously: ```text key 1 → Learn Next.js → checked ``` Now: ```text key 1 → Learn Node.js ``` React may reuse the state associated with `key 1`. The result could be: ```text Learn Next.js → unchecked Learn Node.js → checked ``` The checkbox state appears to move to the wrong item. This happens because the index describes the position, not the item's actual identity. --- ## Stable ID vs Array Index Using an index: ```jsx key={index} ``` means: ```text Identity = position in the array ``` Using a unique ID: ```jsx key={todo.id} ``` means: ```text Identity = actual todo item ``` That is much safer. For example: ```jsx todos.map(todo => ( )) ``` Now: ```text todo 101 always has key 101 todo 102 always has key 102 todo 103 always has key 103 ``` Even if the order changes. --- ## Example With Reordering Suppose: ```js const users = [ { id: "a", name: "Asif" }, { id: "b", name: "Rahul" }, { id: "c", name: "Aman" } ]; ``` Initially: ```text a → Asif b → Rahul c → Aman ``` After sorting: ```text c → Aman a → Asif b → Rahul ``` With IDs as keys, React understands: ```text Aman moved Asif moved Rahul moved ``` The components maintain their identities. With indexes: ```text 0 → Aman 1 → Asif 2 → Rahul ``` React only sees positions: ```text 0 1 2 ``` Those keys did not change, even though completely different users now occupy those positions. That can lead to incorrect component reuse. --- ## What Makes a Good React Key? A good key should be: ### 1. Unique Among Siblings For example: ```jsx key={user.id} ``` Each sibling should have a different key. --- ### 2. Stable Between Renders The same item should have the same key on future renders. Good: ```jsx key={user.id} ``` Bad: ```jsx key={Math.random()} ``` Why? Because: ```js Math.random() ``` produces a different value on every render. React then sees: ```text Old component key: 0.345 New component key: 0.912 ``` and assumes they are different components. This can cause the old component to be unmounted and a new one to be mounted. --- ## Why `Math.random()` Is Even Worse Do not do this: ```jsx users.map(user => ( )) ``` Every render generates completely new keys. Conceptually: ```text Render 1 0.123 → Asif 0.456 → Rahul ``` Next render: ```text Render 2 0.764 → Asif 0.891 → Rahul ``` React sees completely different keys. So instead of reusing the components, it may recreate them. This can: * Reset local state * Trigger unnecessary mounts and unmounts * Cause extra rendering work * Hurt performance --- ## Where Should the Key Be Added? The `key` should be placed on the element directly returned from `map()`. Correct: ```jsx users.map(user => ( )) ``` Not: ```jsx users.map(user => (

{user.name}

)) ``` Here, the key is too deep. React needs the key on the list item being created by the mapping operation. --- ## Keys Only Need to Be Unique Among Siblings A key does not need to be globally unique across the entire application. For example: ```jsx function UserList({ users }) { return users.map(user => ( )); } ``` And somewhere else: ```jsx function AdminList({ admins }) { return admins.map(admin => ( )); } ``` Both lists could contain: ```text key="1" ``` without a problem because they belong to different sibling lists. The requirement is: ```text Keys must be unique among sibling elements. ``` --- ## Can You Access `key` as a Prop? No. Consider: ```jsx ``` Inside: ```jsx function User(props) { console.log(props.key); } ``` `props.key` will not contain the React key. `key` is a special React attribute used internally. If the component also needs the ID, pass it separately: ```jsx ``` Then: ```jsx function User({ userId, name }) { console.log(userId); return

{name}

; } ``` --- ## Is Using an Array Index as a Key Always Wrong? No. Using an array index can be acceptable when the list is completely static. For example: ```jsx const technologies = [ "React", "Next.js", "Node.js" ]; ``` If these items: ```text never get reordered never get removed never get inserted do not contain independent component state ``` then this may be acceptable: ```jsx technologies.map((technology, index) => (

{technology}

)) ``` However, if a stable unique identifier exists, it is generally better to use that. --- ## Good and Bad Keys ### Good ```jsx key={user.id} ``` ```jsx key={product.id} ``` ```jsx key={comment.id} ``` ```jsx key={todo.id} ``` These values represent the actual identity of the data. --- ### Potentially Bad ```jsx key={index} ``` Problematic when the list changes order or items are inserted or removed. --- ### Bad ```jsx key={Math.random()} ``` The key changes on every render. --- ### Also Bad ```jsx key={Date.now()} ``` This can also generate unstable keys. --- ## Easy Way to Remember Think of keys like a person's Aadhaar number or employee ID. Suppose employees are displayed in this order: ```text Position 0 → Asif Position 1 → Rahul Position 2 → Aman ``` The position is not their identity. If Rahul moves to the first position: ```text Position 0 → Rahul Position 1 → Asif Position 2 → Aman ``` Rahul is still Rahul. His unique ID should remain the same. Similarly: ```text Array index = current position Stable key = actual identity ``` React needs the actual identity. --- ## Keys and React Reconciliation A useful interview concept is: ```text Previous children ↓ React compares ↓ New children ↓ Keys help match old and new elements ``` If React finds the same: ```text element type + key ``` it can generally treat that element as the same component identity. If the key changes, React can treat it as a different component. That is why keys are important not only for list performance but also for maintaining component identity and state. --- ## Interview-Ready Answer Keys are required when rendering lists because they give each element a stable identity. During reconciliation, React uses keys to determine which items were added, removed, moved, or remained unchanged. A good key should be unique among its siblings and stable across renders. A database ID or another persistent identifier is usually the best choice. Using an array index as a key is often a poor choice because the index represents the item's position rather than its identity. If an item is inserted, removed, sorted, or reordered, indexes can become associated with different items. React may then reuse the wrong component instance, which can cause incorrect local state, unexpected UI behavior, and unnecessary rendering. Array indexes can be acceptable for truly static lists that never change order, but stable IDs should generally be preferred when available. ### One-Line Interview Answer > React keys give list elements a stable identity during reconciliation, allowing React to correctly match items between renders. Array indexes are often poor keys because their relationship to an item changes when the list is inserted into, deleted from, or reordered, which can cause incorrect component state and unnecessary rendering.