随着 VueJS 的使用越来越广泛,出现了几种最佳实践并逐渐成为标准。

1.始终在 v-for 中使用 :key

在需要操纵数据时,将key属性与v-for指令一起使用可以让程序保持恒定且可预测。

这是很有必要的,这样Vue就可以跟踪组件状态,并对不同的元素有一个常量引用。在使用动画或Vue转换时,key 非常有用。

如果没有key ,Vue只会尝试使DOM尽可能高效。 这可能意味着v-for中的元素可能会出现乱序,或者它们的行为难以预测。 如果我们对每个元素都有唯一的键引用,那么我们可以更好地预测Vue应用程序将如何精确地处理DOM操作。

  1. <!-- 不好的做法-->
  2. <div v-for='product in products'> </div>
  3. <!-- 好的做法 -->
  4. <div v-for='product in products' :key='product.id'>

在事件中使用短横线命名

在发出定制事件时,最好使用短横线命名,这是因为在父组件中,我们使用相同的语法来侦听该事件。

因此,为了确保我们各组件之间的一致性,并使您的代码更具可读性,请在两个地方都坚持使用短横线命名。

  1. this.$emit('close-window')
  2. // 在父组件中
  3. <popup-window @close-window='handleEvent()' />

3.使用驼峰式声明 props,并在模板中使用短横线命名来访问 props

最佳做法只是遵循每种语言的约定。 在 JS 中,驼峰式声明是标准,在HTML中,是短横线命名。 因此,我们相应地使用它们。

幸运的是,Vue 已经提供了驼峰式声明和短横线命名之间转换,因此除了实际声明它们之外,我们不必担心任何事情。

  1. // 不好的做法
  2. <PopupWindow titleText='hello world' />
  3. props: { 'title-text': String }
  4. // 好的做法
  5. <PopupWindow title-text='hello world' />
  6. props: { titleText: String }

4.data 应始终返回一个函数

声明组件data时,data选项应始终返回一个函数。 如果返回的是一个对象,那么该data将在组件的所有实例之间共享。

  1. // 不好的做法
  2. data: {
  3. name: 'My Window',
  4. articles: []
  5. }

但是,大多数情况下,我们的目标是构建可重用的组件,因此我们希望每个组件返回一个惟一的对象。我们通过在函数中返回数据对象来实现这一点。

  1. // 好的做法
  2. data () {
  3. return {
  4. name: 'My Window',
  5. articles: []
  6. }
  7. }

5. 不要在同个元素上同时使用v-ifv-for指令

为了过滤数组中的元素,我们很容易将v-ifv-for在同个元素同时使用。

  1. // 不好的做法
  2. <div v-for='product in products' v-if='product.price < 500'>

问题是在 Vue 优先使用v-for指令,而不是v-if指令。它循环遍历每个元素,然后检查v-if条件。

  1. this.products.map(function (product) {
  2. if (product.price < 500) {
  3. return product
  4. }
  5. })

这意味着,即使我们只想渲染列表中的几个元素,也必须遍历整个数组。

这对我们来当然没有任何好处。

一个更聪明的解决方案是遍历一个计算属性,可以把上面的例子重构成下面这样的:

  1. <div v-for='product in cheapProducts'>
  2. computed: {
  3. cheapProducts: () => {
  4. return this.products.filter(function (product) {
  5. return product.price < 100
  6. })
  7. }
  8. }

这么做有几个好处:

  • 渲染效率更高,因为我们不会遍历所有元素

  • 仅当依赖项更改时,才会重使用过滤后的列表

  • 这写法有助于将组件逻辑从模板中分离出来,使组件更具可读性

6.用正确的定义验证我们的 props

可以这条是很重要,为什么?

在设计大型项目时,很容易忘记用于props的确切格式、类型和其他约定。如果你在一个更大的开发团队中,你的同事不会读心术,所以你要清楚地告诉他们如何使用你的组件。

因此,我们只需编写props验证即可,不必费力地跟踪组件来确定props的格式

从Vue文档中查看此示例。

  1. props: {
  2. status: {
  3. type: String,
  4. required: true,
  5. validator: function (value) {
  6. return [
  7. 'syncing',
  8. 'synced',
  9. 'version-conflict',
  10. 'error'
  11. ].indexOf(value) !== -1
  12. }
  13. }
  14. }

7.组件全名使用驼峰或或者短横线

组件的通用命名约定是使用驼峰或短横线。无论我们使用哪咱,最重要的是始终保持一致。我认为驼峰方式 效果最好,因为大多数IDE自动完成功能都支持它。

  1. # 不好的做法
  2. mycomponent.vue
  3. myComponent.vue
  4. Mycomponent.vue
  5. # 好做法
  6. MyComponent.vue

8. 基本组件应该相应地加上前缀

根据Vue样式指南,基本组件是仅包含以下内容的组件:

  • HTML 元素
  • 额外的基础组件
  • 第三方的UI组件

为这些组件命名的最佳实践是为它们提供前缀BaseVApp。同样,只要我们在整个项目中保持一致,可以使用其中任何一种。

  1. BaseButton.vue
  2. BaseIcon.vue
  3. BaseHeading.vue

该命名约定的目的是使基本组件按字母顺序分组在文件系统中。 另外,通过使用webpack导入功能,我们可以搜索与命名约定模式匹配的组件,并将所有组件自动导入为Vue项目中的全局变量。

单实例组件命名应该带有前缀 The

与基本组件类似,单实例组件(每个页面使用一次,不接受任何prop)应该有自己的命名约定。这些组件特定于我们的应用,通常是 footerheadersider

该组件只能有一个激活实例。

  1. TheHeader.vue
  2. TheFooter.vue
  3. TheSidebar.vue
  4. ThePopup.vue

10.保持指令简写的一致性

在Vue开发人员中,一种常见的技术是使用指令的简写。例如:

  • @v-on的简写
  • :v-bind 的简写
  • #v-slot 的简写

在你的Vue项目中使用这些缩写是很好的。但是要在整个项目中创建某种约定,总是使用它们或从不使用它们,会使我们的项目更具内聚性和可读性。

11.不要在“created”和“watch”中调用方法(重点)

Vue开发人员经常犯的一个错误是他们不必要地在createdwatch中调用方法。

其背后的想法是,我们希望在组件初始化后立即运行watch

// 不好的做法 created: () { this.handleChange() }, methods: { handleChange() { // stuff happens } }, watch () { property() { this.handleChange() } }

但是,Vue为此提供了内置的解决方案,这是我们经常忘记的Vue watch属性。

我们要做的就是稍微重组watch并声明两个属性:

1.handler (newVal, oldVal)-这是我们的watch方法本身。

2. immediate: true- 代表如果在 wacth 里声明了之后,就会立即先去执行里面的handler方法,如果为 false就跟我们以前的效果一样,不会在绑定的时候就执行

  1. // 好的做法
  2. methods: {
  3. handleChange() {
  4. // stuff happens
  5. }
  6. },
  7. watch () {
  8. property {
  9. immediate: true
  10. handler() {
  11. this.handleChange()
  12. }
  13. }
  14. }

12. 模板表达式应该只有基本的 JS 表达式

在模板中添加尽可能多的内联功能是很自然的。但是这使得我们的模板不那么具有声明性,而且更加复杂,也让模板会变得非常混乱。

为此,让我们看看Vue样式指南中另一个规范化字符串的示例,看看它有多混乱。

  1. //不好的做法
  2. {{
  3. fullName.split(' ').map(function (word) {
  4. return word[0].toUpperCase() + word.slice(1)
  5. }).join(' ')
  6. }}

基本上,我们希望模板中的所有内容都直观明了。 为了保持这一点,我们应该将复杂的表达式重构为适当命名的组件选项。

分离复杂表达式的另一个好处是可以重用这些值。

  1. // 好的做法
  2. {{ normalizedFullName }}
  3. // The complex expression has been moved to a computed property
  4. computed: {
  5. normalizedFullName: function () {
  6. return this.fullName.split(' ').map(function (word) {
  7. return word[0].toUpperCase() + word.slice(1)
  8. }).join(' ')
  9. }
  10. }

总结

这是12个最常见的最佳实践,它们将使我们的Vue代码更易于维护、可读性更好、更专业。希望这些技巧对您有用(因为它们绝对是我一直想记住的东西)。

12 种使用 Vue 的最佳做法的更多相关文章

  1. Vue中组件通信的几种方法(Vue3的7种和Vue2的12种组件通信)

    Vue3组件通信方式: props $emit expose / ref $attrs v-model provide / inject Vuex 使用方法: props 用 props 传数据给子组 ...

  2. 【译】Permissions Best Practices Android M权限最佳做法

    Permissions Best Practices PreviousNext In this document Consider Using an Intent Don't Overwhelm th ...

  3. SharePoint 2013中的爬网最佳做法

    了解在 SharePoint Server 2013 中爬网的最佳做法 搜索系统对内容进行爬网,以构建一个用户可以对其运行搜索查询的搜索索引.本文包含有关如何最有效地管理爬网的建议. 本文内容: 使用 ...

  4. [转]移动App测试中的最佳做法

    Daniel Knott 用过各种不同编程语言和软件质量保证工具.他在软件开发和测试方面干了七年,自2010年起,他一直在德国汉堡的XING AG公司就职,几个项目里,比如XING调查和XING建议, ...

  5. 移动App测试中的最佳做法

    一说起软件测试,测试员想到肯定是去检查文件,功能,API,性能并确定软件是否安全,以及关于软件特定部分的其他事项.但是对于移动测试,测试员不得不基于用户移动使用模式考虑移动相关的功能. 本文是基于我的 ...

  6. Google advertiser api开发概述——最佳做法&建议

    最佳做法 本指南介绍了一些最佳做法,您可以运用它们来优化 AdWords API 应用的效率和性能. 日常维护 为确保您的应用不间断运行,可采取以下做法: 确保 AdWords API 中心中的开发者 ...

  7. 【转】C# Async/Await 异步编程中的最佳做法

    Async/Await 异步编程中的最佳做法 Stephen Cleary 近日来,涌现了许多关于 Microsoft .NET Framework 4.5 中新增了对 async 和 await 支 ...

  8. 【转】移动App测试中的最佳做法

    一说起软件测试,测试员想到肯定是去检查文件,功能,API,性能并确定软件是否安全,以及关于软件特定部分的其他事项.但是对于移动测试,测试员不得不基于用户移动使用模式考虑移动相关的功能. 本文是基于我的 ...

  9. 每个IT安全专业人员应该知道的12种根本漏洞

    每个IT安全专业人员应该知道的12种根本漏洞 每年,IT安全专业人员都面临着数千个新的软件漏洞和数百万个不同的恶意软件程序,但只有12种根本漏洞会让这些软件漏洞和恶意软件程序攻击你的设备.了解这些根本 ...

随机推荐

  1. Markdown 教程之编辑器

    1. Typora 编辑器 Typora 是一款支持实时预览的 Markdown 文本编辑器.它有 OS X.Windows.Linux 三个平台的版本,并且由于仍在测试中,是完全免费的. 2. 安装 ...

  2. 金字塔卷积:Pyramidal Convolution

    论文地址:https://arxiv.org/pdf/2006.11538.pdf github:https://github.com/iduta/pyconv 作者认为,当前CNN主要存在两个不足: ...

  3. Object#wait()与Object#wait(long)的区别

    例子 例1 最基础的等待-通知 下面一个例子,一个线程"waiting"在同步代码块调用了Object#wait()方法,另一个线程"timedWaiting" ...

  4. Centos 7下编译安装Mysql

    (1)官网下载地址:https://dev.mysql.com/downloads/mysql/ 此处下载的是 mysql-boost-5.7..tar.gz 百度云下载地址:https://pan. ...

  5. variable ans might not have been initialized 报错,以及初始化注意点

    他是说你没有初始化而已,一般只是个warning,如果是在不能跑,那就给他初始化一下. 注意,初始化可不是任意值哈! 就比如如果要算阶乘,你初始化就不能为0. 还有如果是比较大小这类,就不要把初始化统 ...

  6. 初识 Nacos 以及安装

    Nacos简介 前四个字母分别为Naming和Configuration的前两个字母,最后的s为Service. 是什么: 一个更易于构建云原生应用的动态服务发现.配置管理和服务管理平台.Nacos: ...

  7. Java-每日学习笔记(数据库与idea技巧)

    Java杂记-2020.07.28 简单记录下今天项目用到的东西还有技术公众号学到的一些知识点 Java事务 idea编码技巧 数据库快速插入100万条数据 Java实现sql回滚 Java事务 事务 ...

  8. MacOS下Nginx安装

    1. 先安装homebrew 2. 安装Nginx,终端下执行: $ brew install nginx 安装过程中会自己安装依赖: 3. 启动nginx服务 $ nginx 成功后,使用浏览器打开 ...

  9. 使用Spring Validation优雅地校验参数

    写得好的没我写得全,写得全的没我写得好 引言 不知道大家平时的业务开发过程中 controller 层的参数校验都是怎么写的?是否也存在下面这样的直接判断? public String add(Use ...

  10. Django创建简单数据库

    在 创建好的 app 目录下的 models.py 中,编写创建 数据库表的限制条件 class Student(models.Model): s_name = models.CharField(ma ...