关于Vue2和Vue3的区别及组合式/选项式API区别——高频面试题

6230_

于 2024-09-06 10:42:39 发布

阅读量1.5k

点赞数 19

分类专栏：前端基础文章标签： vue.js 前端开发语言前端框架 html 面试改行学it

本文链接：https://blog.csdn.net/2301_78675670/article/details/141953078

版权

前端基础专栏收录该内容

21 篇文章 0 订阅

订阅专栏

1、vue2和vue3的区别

以下包含但不仅仅只有这10条区别
但是，在应对面试时，回答已经足够用了，这些也是vue2和vue3的主要区别

Composition API vs Options API
- Composition API：组合式API
- Options API：选项式API——在vue2中使用
- 它们两者在vue3中是组织代码的不同方式
- Vue3引入了Composition API，更灵活、易于组织代码，相较于Vue2的Options API更具优势。
性能优化
- Vue3在虚拟DOM和响应式系统方面进行了多项性能优化，提升了页面加载速度和渲染效率。
- 使用了更高效的算法减少了不必要的dom更新
- 使用了proxy对属性的变化进行监听，并在需要进行页面更新的时候批量的进行操作
TypeScript支持
- 简称TS——它其实就是一种静态类型的检查工具，方便在开发的时候就发现问题
- Vue3更好地支持TypeScript，提供更好的类型检查和推断，有助于减少潜在错误。
新增功能
- Vue3引入了Teleport、Suspense等新功能，简化了处理复杂逻辑和异步操作的方式。
- 方便的把组件中的一些dom模板移动到dom树中的任何内容、任何位置
树型组件优化
- Vue3优化了树型组件的性能，特别是对于大型列表的渲染，表现更为出色。
全局API调整
- Vue3对全局API进行了调整和统一，使整个框架更加一致和易于理解。
包大小优化
- Vue3的包大小相较于Vue2有所减小，剔除了一些冗余代码，提升了整体性能。
Tree-shaking效果
- Vue3采用ES模块组织代码，优化了Tree-shaking的效果，减少了不必要的代码被打包到生产环境。
- Tree-shaking：打包编译时把一些不必要的代码自动剔除掉
更佳的响应式原理
- Vue3重新设计了响应式系统，使变化侦测更加精确高效，提供更出色的性能表现。
逻辑复用与共享
- Composition API让逻辑复用和共享更加便捷灵活，让代码组织更加清晰和高效。

注意：以上不是所有的区别内容
○ 但是，面试回答已经足够用了，也是主要的区别

2、组合式/选项式API区别

对比Composition API与Options API，及Composition API的优点和缺点
注意：vue3里两种API是都支持的！
选项式API：
在简单应用和迁移现有项目时可能更方便——也就是：处理一些简单的组件，或者是快速开发的时候更方便、更有用

组合式API：
则在需要更好的代码组织和重用时更具优势——也就是：高度复用的一些逻辑场景

Vue 3的设计目标之一是：保持向后兼容性，因此它完全支持这两种编写方式，使开发者可以灵活地选择适合自己项目的方式。

2.1、对比

组织方式：
- Composition API以函数的形式组织代码，将相关逻辑聚合在一起，提高代码的可读性和可维护性；
- 而Options API将数据、计算属性和方法等放置在同一个选项对象中，可能导致代码在不同选项中分散，降低可读性和可维护性。
逻辑复用：
- Composition API更便于逻辑的复用和共享，通过函数的方式组织代码，使得在不同组件之间高效共享逻辑代码，提高代码重用性；
- 而Options API相对而言，逻辑复用需要更多的手动努力和处理。
类型推断：
- Composition API对于使用强类型语言（如TypeScript）的开发者更友好，具有更好的类型推断能力，可以发现潜在的类型错误，提高代码质量和稳定性；
- 而Options API的类型推断能力相对较弱。

2.2、Composition API的优点

逻辑复用：
- Composition API使逻辑复用变得更加方便，可以更高效地在不同组件中共享代码。
清晰的代码结构：
- 通过根据逻辑关注点组织代码，Composition API可以获得更清晰、易于理解的代码结构，有助于团队协作和代码维护。
更好的类型推断：
- Composition API在使用强类型语言时具有更好的类型推断能力，能够帮助开发者及早发现和避免潜在的类型错误。

2.3、Composition API的缺点

学习曲线较陡
- 对于已经熟悉Options API的开发者来说，适应和学习Composition API可能需要一定的时间和努力，因为它涉及到不同的用法和思维方式。
开发者之间的转换成本
- 如果团队中的开发者之间在不同项目中频繁切换，从Options API转换到Composition API可能会带来额外的学习和适应成本。

2.4、示例

需求：假设我们有一个页面上的计数器需求，点击按钮时实现数量加一的功能。
以下是使用Composition API和Options API实现同样功能的示例代码：

2.4.1、Composition API(组合式)示例

// 1、html结构
    <template>
       <button @click="increment">Click to Increment: {{ count }}</button>
    // 1）再次创建按钮 => 执行减减操作
       <button @click="incrementb">Click to Increment: {{ count }}</button>
    </template>

// 2、js逻辑
    <script>
       import { ref } from 'vue';
       export default {
         setup() {
            const count = ref(0); // 这个变量使用ref创建的 => vue3中响应式数据，使用ref来创建
            const increment = () => {
              count.value++;
            };
      // 2）当还需要再写一个自减的类似逻辑时，可以把相同的逻辑和相同的变量写在一起 
      // 3）一组组的逻辑放在一起，今后在剥离逻辑或重用逻辑的时侯，相同的功能写在一起，也就增加了代码可读性
            const countb = ref(0); // 这个变量使用ref创建的 => vue3中响应式数据，使用ref来创建
            const incrementb = () => {
              count.value--;
            };
            return {
              count,
              increment
            };
         }
      };
    </script>

2.4.2、Options API(选项式)示例

// 1、html结构
    <template>
      <button @click="increment">Click to Increment: {{ count }}</button>
    </template>
      
// 2、js逻辑
    <script>
      export default {
        data() {
          return {
            count: 0
          };
        },
        methods: {
          increment() {
            this.count++;
          }  
        }
      };
    </script>

2.4.3、结论

在以上示例中，可以看到Composition API将相关逻辑集中在一起，使得代码更易于理解和维护
- 当需要再次增加一个按钮时，不管是完全相同的逻辑，还是类似的逻辑，把它们写在一起时，可以大大提升代码的可读性
- 比如，都是用到了某个变量，那么就不需要再次单独在声明变量，可以直接使用
- 注意：按钮逻辑复杂度增加时，将它们写在一起可能会导致代码过于臃肿和难以理解，按钮之间的逻辑并不相关，将它们放在一起可能会导致代码结构混乱，不利于后续维护和修改，这里是AI给予的提醒
而Options API则可能导致代码分散在不同选项中，降低了代码的清晰度和可读性。
- 当相同逻辑增加时，如果选择在methods中增加方法，会导致代码量越来越大
- 同样，如果需要对某个数据进行递减，就需要再次在data中声明变量，那么随着项目的变大，变量也会越写越多，但其实数据用的都是一个