总是用 `key` 配合 `v-for`。
~~~
// 好例子
<ul>
<li
v-for="todo in todos"
:key="todo.id"
>
{{ todo.text }}
</li>
</ul>
~~~
在组件上*总是*必须用 `key` 配合 `v-for`,以便维护内部组件及其子树的状态。甚至在元素上维护可预测的行为,比如动画中的[对象固化 (object constancy)](https://bost.ocks.org/mike/constancy/),也是一种好的做法。
#### 详解
假设你有一个待办事项列表:
~~~
data: function () {
return {
todos: [
{
id: 1,
text: '学习使用 v-for'
},
{
id: 2,
text: '学习使用 key'
}
]
}
}
~~~
然后你把它们按照字母顺序排序。在更新 DOM 的时候,Vue 将会优化渲染把可能的 DOM 变动降到最低。即可能删掉第一个待办事项元素,然后把它重新加回到列表的最末尾。
这里的问题在于,不要删除仍然会留在 DOM 中的元素。比如你想使用 `<transition-group>` 给列表加过渡动画,或想在被渲染元素是 `<input>` 时保持聚焦。在这些情况下,为每一个项目添加一个唯一的键值 (比如 `:key="todo.id"`) 将会让 Vue 知道如何使行为更容易预测。
根据我们的经验,最好*始终*添加一个唯一的键值,以便你和你的团队永远不必担心这些极端情况。也在少数对性能有严格要求的情况下,为了避免对象固化,你可以刻意做一些非常规的处理。
~~~
// 反例
<ul>
<li v-for="todo in todos">
{{ todo.text }}
</li>
</ul>
~~~
- Vue开发规范
- 基于模块开发
- 组件
- 组件命名规则
- 基础组件名
- 单例组件名
- 紧密耦合的组件名
- 组件名中的单词顺序
- 组件文件夹命名规则
- method方法
- methods方法命名规则
- 组件结构化
- 组件事件命名规则
- v-for与v-if
- 为 v-for 设置键值
- 避免 v-if 和 v-for 用在一起
- Prop
- Prop命名规则
- Prop定义
- 避免 this.$parent
- 谨慎使用 this.$refs
- 隐性的父子组件通信
- 元素
- 元素特性的顺序
- 多个特性的元素摆放规则
- 单文件组件的顶级元素的顺序
- 简化代码
- 模板中简单的表达式
- 简单的计算属性
- 指令缩写
- 文件引用路径
- 其他注意
- 组件数据
- 将 this 赋值给 component 变量
- 对组件文件进行代码校验
- 尽可能使用 mixins
- 非 Flux 的全局状态管理
- 只在需要时创建组件
- HTML开发规范
- HTML语法
- HTML5 doctype
- 语言属性
- IE 兼容模式
- 字符编码
- 引入 CSS 和 JavaScript 文件
- 实用为王
- 属性顺序
- 布尔(boolean)型属性
- 减少标签的数量
- JavaScript 生成的标签
- CSS开发规范
- CSS语法
- 声明顺序
- 不要使用 @import
- 媒体查询(Media query)的位置
- 带前缀的属性
- 单行规则声明
- 简写形式的属性声明
- Less 和 Sass 中的嵌套
- Less 和 Sass 中的操作符
- 注释
- class 命名
- 选择器
- 代码组织