Why is it not recommended to use index as the key attribute value in Vue?

Preface

In front-end development, as long as list rendering is involved, whether it is React or Vue framework, it will prompt or require each list item to use a unique key. Many developers will directly use the array index as the key value without knowing the principle of the key. This article will explain the role of key and why it is best not to use index as the attribute value of the key.

The role of key

Vue uses virtual DOM and compares the old and new DOM according to the diff algorithm to update the real DOM. The key is the unique identifier of the virtual DOM object. The key plays an extremely important role in the diff algorithm.

The role of key in the diff algorithm

In fact, the diff algorithms in React and Vue are roughly the same, but the diff comparison methods are still quite different, and even the diffs of each version are quite different. Next, we will take the Vue3.0 diff algorithm as the starting point to analyze the role of key in the diff algorithm

The specific diff process is as follows

In Vue3.0, there is such a source code in the patchChildren method

if (patchFlag > 0) {
      if (patchFlag & PatchFlags.KEYED_FRAGMENT) { 
         /* For the case where a key exists, use the diff algorithm */
        patchKeyedChildren(
         ...
        )
        return
      } else if (patchFlag & PatchFlags.UNKEYED_FRAGMENT) {
         /* If the key does not exist, patch it directly */
        patchUnkeyedChildren( 
          ...
        )
        return
      }
    }

patchChildren performs a real diff or a direct patch depending on whether the key exists. We will not delve into the case where the key does not exist.

Let's first look at some declared variables.

/* c1 old vnode c2 new vnode */
let i = 0 /* record index */
const l2 = c2.length /* Number of new vnodes*/
let e1 = c1.length - 1 /* Index of the last node of the old vnode*/
let e2 = l2 - 1 /* The index of the last node of the new node*/

Synchronize head node

The first step is to find the same vnode from the beginning, and then patch it. If it is not the same node, then jump out of the loop immediately.

//(ab) c
//(ab) de
/* Compare from the beginning to find the same node patch, if different, jump out immediately*/
    while (i <= e1 && i <= e2) {
      const n1 = c1[i]
      const n2 = (c2[i] = optimized
        ? cloneIfMounted(c2[i] as VNode)
        : normalizeVNode(c2[i]))
        /* Check if key and type are equal*/
      if (isSameVNodeType(n1, n2)) {
        patch(
          ...
        )
      } else {
        break
      }
      i++
    }

The process is as follows:

isSameVNodeType is used to determine whether the current vnode type is equal to the vnode key

export function isSameVNodeType(n1: VNode, n2: VNode): boolean {
  return n1.type === n2.type && n1.key === n2.key
}

In fact, seeing this, we already know the role of key in the diff algorithm, which is to determine whether it is the same node.

Synchronize tail node

The second step starts from the end with the same diff as before

//a (bc)
//de (bc)
/* If the first step is not patched, immediately start patching from the back to the front. If you find any differences, jump out of the loop immediately*/
    while (i <= e1 && i <= e2) {
      const n1 = c1[e1]
      const n2 = (c2[e2] = optimized
        ? cloneIfMounted(c2[e2] as VNode)
        : normalizeVNode(c2[e2]))
      if (isSameVNodeType(n1, n2)) {
        patch(
         ...
        )
      } else {
        break
      }
      e1--
      e2--
    }

After the first step, if it is found that the patch is not complete, then immediately proceed to the second step, starting from the end and traversing forward diff. If it is not the same node, then jump out of the loop immediately. The process is as follows:

Adding a new node

Step 3: If all old nodes are patched and new nodes are not patched, create a new vnode

//(ab)
//(ab) c
//i = 2, e1 = 1, e2 = 2
//(ab)
//c (ab)
//i = 0, e1 = -1, e2 = 0
/* If the number of new nodes is greater than the number of old nodes, all remaining nodes will be processed as new vnodes (this means that the same vnode has been patched) */
    if (i > e1) {
      if (i <= e2) {
        const nextPos = e2 + 1
        const anchor = nextPos < l2 ? (c2[nextPos] as VNode).el : parentAnchor
        while (i <= e2) {
          patch( /* create a new node */
            ...
          )
          i++
        }
      }
    }

The process is as follows:

Delete redundant nodes

Step 4: If all new nodes are patched and there are some old nodes left, uninstall all old nodes.

//i > e2
//(ab) c
//(ab)
//i = 2, e1 = 2, e2 = 1
//a (bc)
//(bc)
//i = 0, e1 = 0, e2 = -1
else if (i > e2) {
   while (i <= e1) {
      unmount(c1[i], parentComponent, parentSuspense, true)
      i++
   }
}

The process is as follows:

Longest increasing subsequence

At this point, the core scene has not yet appeared. If we are lucky, it may end here, but we cannot rely entirely on luck. The remaining scenario is that both the new and old nodes have multiple child nodes. Next, let’s see how Vue3 does it. To combine move, add and uninstall operations

Every time we move an element, we can find a pattern. If we want to move it the least number of times, it means that some elements need to be stable. So what are the patterns for elements that can remain stable?

Take a look at the example above: c h d e VS d e i c. When comparing, you can see with the naked eye that you only need to move c to the end, then uninstall h and add i. d e can remain unchanged. It can be found that the order of d e in the new and old nodes remains unchanged. d is after e, and the subscript is in an increasing state.

Here we introduce a concept called the longest increasing subsequence.
Official explanation: In a given array, find a set of increasing values ​​with the largest possible length.
It's a bit hard to understand, so let's look at a specific example:

const arr = [10, 9, 2, 5, 3, 7, 101, 18]
=> [2, 3, 7, 18]
This array is the longest increasing subsequence of arr, and so is [2, 3, 7, 101].
So the longest increasing subsequence meets three requirements:
1. The values ​​in the subsequence are increasing
2. The subscripts of the values ​​in the subsequence are increasing in the original array
3. This subsequence is the longest one that can be found, but we usually find the set of sequences with smaller values ​​because they have more room to grow.

The next idea is: if we can find the nodes whose order in the new node sequence remains unchanged, we will know which nodes do not need to be moved, and then we only need to insert the nodes that are not here. Because the final order to be presented is the order of the new nodes, and movement is just the movement of the old nodes, so as long as the old nodes keep the longest order unchanged, they can be kept consistent with it by moving individual nodes. So before that, find all the nodes first, and then find the corresponding sequence. What we actually want to get in the end is this array: [2, 3, new, 0]. In fact, this is the idea of ​​​​diff movement

Why not use index?

Performance cost

When using index as key, the sequential operation is destroyed, because each node cannot find the corresponding key, some nodes cannot be reused, and all new vnodes need to be recreated.

example:

<template>
  <div class="hello">
    <ul>
      <li v-for="(item,index) in studentList" :key="index">{{item.name}}</li>
      <br>
      <button @click="addStudent">Add a piece of data</button>
    </ul>
 
  </div>
</template>
 
<script>
export default {
  name: 'HelloWorld',
  data() {
    return {
      studentList: [
        { id: 1, name: '张三', age: 18 },
        { id: 2, name: 'Li Si', age: 19 },
      ],
    };
  },
  methods:{
    addStudent(){
      const studentObj = { id: 3, name: '王五', age: 20 };
      this.studentList=[studentObj,...this.studentList]
    }
  }
}
</script>

Let's open the Chorme debugger first, and then double-click to modify the text inside.

Let's run the above code and see the results.

From the above running results, we can see that we only added one piece of data, but all three pieces of data need to be re-rendered. Isn’t it surprising? I clearly only inserted one piece of data, why do all three pieces of data need to be re-rendered? And all I want is to render the newly added data.

We have also talked about the diff comparison method above. Now let's draw a picture based on the diff comparison to see how the comparison is done.

When we add a piece of data in front, the index order will be interrupted, causing all the keys of the new nodes to change, so the data on our page will be re-rendered.

Next, we generate 1000 DOMs to compare the performance of using index and not using index. In order to ensure the uniqueness of the key, we use uuid as the key.

Let's use index as the key and execute it once

<template>
  <div class="hello">
    <ul>
      <button @click="addStudent">Add a piece of data</button>
      <br>
      <li v-for="(item,index) in studentList" :key="index">{{item.id}}</li>
    </ul>
  </div>
</template>
 
<script>
import uuidv1 from 'uuid/v1'
export default {
  name: 'HelloWorld',
  data() {
    return {
      studentList: [{id:uuidv1()}],
    };
  },
  created(){
    for (let i = 0; i < 1000; i++) {
      this.studentList.push({
        id: uuidv1(),
      });
    }
  },
  beforeUpdate(){
    console.time('for');
  },
  updated(){
    console.timeEnd('for') //for: 75.259033203125 ms
  },
  methods:{
    addStudent(){
      const studentObj = { id: uuidv1() };
      this.studentList=[studentObj,...this.studentList]
    }
  }
}
</script>

Replace id as key

<template>
  <div class="hello">
    <ul>
      <button @click="addStudent">Add a piece of data</button>
      <br>
      <li v-for="(item,index) in studentList" :key="item.id">{{item.id}}</li>
    </ul>
  </div>
</template>
  beforeUpdate(){
    console.time('for');
  },
  updated(){
    console.timeEnd('for') //for: 42.200927734375 ms
  },

From the above comparison, we can see that using a unique value as a key can save overhead

Data Misalignment

In the above example, you may think that using index as key only affects the efficiency of page loading, and think that a small amount of data has little impact. In the following case, using index may cause some unexpected problems. Still in the above scenario, I first add an input box after each text content, and manually fill in some content in the input box, and then use the button to append a classmate forward.

<template>
  <div class="hello">
    <ul>
      <li v-for="(item,index) in studentList" :key="index">{{item.name}}<input /></li>
      <br>
      <button @click="addStudent">Add a piece of data</button>
    </ul>
  </div>
</template>
 
<script>
export default {
  name: 'HelloWorld',
  data() {
    return {
      studentList: [
        { id: 1, name: '张三', age: 18 },
        { id: 2, name: 'Li Si', age: 19 },
      ],
    };
  },
  methods:{
    addStudent(){
      const studentObj = { id: 3, name: '王五', age: 20 };
      this.studentList=[studentObj,...this.studentList]
    }
  }
}
</script>

Let's enter some values ​​into the input and add a classmate to see the effect:

At this time we will find that the data entered before adding is misplaced. After adding, Zhang San's information remains in Wang Wu's input box, which is obviously not the result we want.

From the comparison above, we can see that because the index is used as the key, when comparing, it is found that although the text value has changed, when continuing to compare downward, it is found that the Input DOM node is still the same as before, so it is reused. However, it is unexpected that the input input box retains the input value, and at this time, the input value will be misplaced.

Solution

Since we know that using index can have a very bad impact in some cases, how do we solve this problem during development? In fact, as long as the key is unique and unchanged, the following three situations are generally used more frequently in development.

• In development, it is best to use a unique identifier as the key for each piece of data, such as the unique value returned by the background, such as the ID, mobile phone number, ID number, etc.
• You can use Symbol as the key. Symbol is a new primitive data type introduced in ES6. It represents a unique value and is mostly used to define the unique property name of an object.

let a=Symbol('test')
let b = Symbol('test')
console.log(a===b) //false

You can use uuid as the key. uuid is the abbreviation of Universally Unique Identifier. It is a machine-generated identifier that is unique within a certain range (from a specific name space to the world).

We use the first solution above as the key and look at the above situation again, as shown in the figure. Nodes with the same key are reused. This is the real effect of the diff algorithm.

Summarize

• When using index as the key, unnecessary real DOM updates will be generated when the data is added or deleted in reverse order, resulting in low efficiency.
• When using index as the key, if the structure contains DOM of the input class, incorrect DOM updates will occur
• In development, it is best to use a unique identifier as the key for each piece of data, such as the unique value returned by the background, such as the ID, mobile phone number, ID number, etc.
• If there is no operation that destroys the order, such as adding or deleting data in reverse order, and it is only used for rendering and display, it is also possible to use index as the key (but it is still not recommended to develop good development habits).

This concludes this article on why it is not recommended to use index as key in Vue. For more relevant content about Vue index as key, please search 123WORDPRESS.COM’s previous articles or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!