Replies: 1 comment
-
|
It is a good habbit, but for a) static content that never changes or b) small lists it doesn't really matter tbh. Providing a (unique) key is giving a hint to Vue compiler to work with VNodes in virtual DOM effectively when re-rendering long lists. It can then diff state before and after and pre-calculate which changes must be done and leave other elements in the tree completely intact. But to start getting measurable performace gains, we must talk about hundreds or even thousands of items that are rendered. It is also true that for really large and performance-demanding lists, it is rather recommended to use 3rd party services anyway - https://vuejs.org/guide/best-practices/performance.html#virtualize-large-lists |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
basically, i don't generally see a difference in the behavior changing with or without key. From the Vue.js Docs it said having it would help trigger events properly, and reading somewhere off the internet that it helps to locate some stuff related to the virtual DOM to reduce extra renders and things being in order if there were any remove/delete actions going on. But I'm not planning on allowing removal/delete of anything here, and I understand vue changes a lot of things from vue2 to vue3, I'm using vue3 with composition API in mind. Does the key matter at all still?
<li v-for="comment in pageComments(page)" :key="comment.id" class="rounded border p-3">for the full boilerplate
Beta Was this translation helpful? Give feedback.
All reactions