Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: Rendering a list with duplicate keys causes unexpected behavior in reconciliation #31608

Open
kansalanmol0609 opened this issue Nov 21, 2024 · 0 comments
Labels
Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug

Comments

@kansalanmol0609
Copy link

Rendering a list with duplicate keys causes unexpected behavior in reconciliation. Not sure if this is a bug or not.

React version: v18.0.0

Steps To Reproduce

  1. Create a list of items with duplicate strings.
  2. Render the list using map, assigning key directly as the string value of each item.
  3. Use either useEffect or useLayoutEffect to update the list state after the component mounts.
  4. Observe the DOM output when the state updates.

Link to code example:

import { useLayoutEffect, useState } from "react";  

export default function App() {  
  const [items, setItems] = useState(["name2", "name3", "name4", "name4"]);  

  useLayoutEffect(() => {  
    setItems(["name1", "name2", "name3", "name4"]);  
  }, []);  

  return (  
    <div>  
      {items.map((item) => (  
        <div key={item}>{item}</div>  
      ))}  
    </div>  
  );  
}  

The current behavior

When using either useEffect or useLayoutEffect:

The rendered DOM contains 5 items instead of 4. React fails to reconcile the list correctly due to duplicate keys, retaining an extra DOM node.

The expected behavior

React should handle the state update and reconciliation correctly, ensuring that the rendered DOM contains only the updated list of items (4 items in this case). Duplicate keys should not lead to unexpected rendering issues.

@kansalanmol0609 kansalanmol0609 added the Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug label Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug
Projects
None yet
Development

No branches or pull requests

1 participant