This algorithm is used by react.js underhood to carry out the reconciliation process with ease.

It works with 2 assumptions :

1. If any two elements change they will be creating two different trees.

This seems obvious as there’s no rocket science behind this, but in react.js this may sometimes create a huge blunder when not kept in mind.

1. When working with a list of child elements which often changes, should be provided with a unique “key” as a prop.

Now this asks for a detailed explanation cause, yeah it’s confusing at least for me for the first time.

So to pass a unique key there are two ways:

• by passing it as an index,

• by passing it as the index.id,

  But why do we have to use a unique key, the reason behind this is simple to perform reconciliation, React's reconciliation process ****which is responsible for updating the UI.

  During this, React lies on the key prop to uniquely identify each element in a list. This helps React determine:

  1. Which elements were added.
  2. Which elements were removed.
  3. Which elements were reordered.

  If the key is not stable or unique, React might incorrectly associate items in the list, leading to:

  • Performance issues (re-rendering more than necessary).
  • Incorrect UI behavior (e.g., preserving wrong DOM states like input values or animations).

  Now let’s know why not to use just index as a key.

WHY IS index A BAD KEY?

• If items in the array are re-ordered then the keys will also get changed due to which, React may think items with the same index are the same element and won't update them correctly.
• If you use the index as the key, React might reuse DOM nodes for different data.

Example:

const todos = [ { id: 1, name: "Buy groceries" }, { id: 2, name: "Walk the dog" }, ];

now user changes the order to:

const todos = [ { id: 2, name: "Walk the dog" },

{ id: 1, name: "Buy groceries" }, ];

In this react will check the key and find that the key has changed, which will result in displaying the wrong data to the user.