94 lines
6.0 KiB
Plaintext
94 lines
6.0 KiB
Plaintext
1.Vue2和Vue3的区别
|
||
1>Vue2使用Object.defineProperty 为每个属性创建getter和setter，通过getter和setter来捕获操作以实现响应式更新； 很多情况下，属性的新增和删除拦截不到
|
||
Vue3 通过Proxy实现，proxy是ES6新特性，提供了更多的拦截操作；能监听到属性的删除和新增
|
||
|
||
2>vue3支持碎片化
|
||
v2中只能存在一个根节点，v3中可以保持如下多个根节点，一定程度上减少了标签的层级
|
||
|
||
3>生命周期不同
|
||
大部分生命周期在vue2的周期前加 on 即可；vue3没有beforeCreate 和 created两个周期
|
||
|
||
4>去除this
|
||
Vue3中没有this， 使用this报错 需要组件内的某个方法直接使用即可
|
||
|
||
5>组件传值props和emit
|
||
Vue2中是 props和 this.$emit Vue3中则是[defineEmits defineProps] props emit；
|
||
需要注意的是 Vue2中传值给子组件可以的属性可以直接使用，Vue3中子组件接收的值在props对象中，所以在ts/js中使用需要 props.name
|
||
emit触发的事件，需要defineProps声明接收数据，defineEmits 声明以明确事件定义
|
||
|
||
6>watch和computed不同
|
||
watch，computed与vue2用法差别不大，写法改变了； vue2是将要监听的值放在watch:{ }中
|
||
Vue3，监听watch第一个参数是直接传入要监听的对象 ；深度监听复杂对象 {deep： true}
|
||
|
||
7>子组件实例，调用组件方法
|
||
Vue2中 子组件定义ref="name"后使用this.$refs.name 就能拿到组件name的实例；同时可以this.$refs.name.test() 的方式直接调用子组件的test()方法
|
||
Vue3中，子组件定义ref="name"，需要用ref()来定义引用，将其绑定到对应子组件上；若想直接调用子组件的方法，需要在子组件中defineExpose显示暴露出对应的方法（组件封装性），若不暴露出来则子组件实例上不会存在此方法
|
||
|
||
8>选项式api和组合式api
|
||
Vue2中 选项式的api，创建组件时需要使用各种选项 data methods watch等
|
||
Vue3组合式允许将相关的代码逻辑放在一起处理，让代码更易于理解和维护
|
||
|
||
9>mixins和hooks
|
||
Vue 2 中，Mixins 是一种全局特性，可以在多个组件之间共享代码。你可以创建一个 Mixin 对象，然后在组件中通过 Mixins 选项引入这个对象，从而将 Mixin 中的属性和方法合并到组件中；如果多个 Mixins 中有相同的属性或方法，可能会导致命名冲突。另外，由于 Mixins 是全局的，它们会增加组件的耦合度，使得代码难以维护
|
||
|
||
Vue3的Hooks允许你将相关的逻辑组合到一起，形成一个逻辑单元，组件内部使用的，而不是全局的，这减少了命名冲突和耦合度。
|
||
|
||
2.TypeScript VS JavaScript 对比区别
|
||
|
||
1>语法
|
||
TS 静态类型注解，类和接口定义，枚举类型，装饰器等
|
||
JS 基本的面向对象语法，原型链继承，匿名函数等
|
||
|
||
2>类型系统
|
||
TS 强大的静态类型系统，类型推断，类型注解，联合类型，交叉类型，泛型支持，严格的类型检查
|
||
JS 动态类型系统，基于值的类型推断，灵活但容易出错
|
||
3>工具支持
|
||
TS 强大的编辑器支持（如 Visual Studio Code），代码补全，类型检查，重构功能，错误提示，智能感知，自动导入等
|
||
JS基本的编辑器支持，某些编辑器提供基本的代码补全和错误提示
|
||
|
||
4>类型声明文件支持
|
||
TS 丰富的类型声明文件生态系统，用于描述 JavaScript 库的类型，提供了良好的第三方库和框架的类型定义
|
||
JS JavaScript 库的类型声明文件相对较少，需要手动编写或通过社区维护
|
||
|
||
5>类型安全
|
||
TS 静态类型检查使得编码过程中能够尽早发现类型错误和潜在问题，提高代码质量和可维护性
|
||
JS 动态类型系统导致类型错误只能在运行时才能发现，可通过测试覆盖率、代码质量工具等方式减少错误出现的概率
|
||
|
||
6>性能
|
||
TS 编译过程会引入额外的开销，但生成的 JavaScript 代码在运行时性能与直接编写的 JavaScript 代码相当
|
||
JS 更简单的解释执行，没有额外的编译开销，运行效率相对较高
|
||
|
||
7>迁移成本
|
||
TS 在现有 JavaScript 项目中引入 TypeScript 需要进行一定的迁移工作，并对代码进行类型注解。但可以逐步完成迁移过程，避免一次性的大规模重构
|
||
JS 无需迁移成本，现有的 JavaScript 代码可以直接运行
|
||
|
||
8>社区和生态系统
|
||
TS 日益壮大的社区，活跃的开发者社区，丰富的第三方库和工具支持，官方和社区维护的文档和教程
|
||
JS 世界最大的开源生态系统之一，庞大的开发者社区和资源
|
||
|
||
9>适用场景
|
||
TS 大型项目和团队合作，需要更强类型安全性和工具支持的项目；前端框架和库开发，需要构建复杂的应用逻辑和可重用的组件；需要长期维护的项目；与其他静态类型语言集成的项目
|
||
JS 快速原型开发，小型项目，脚本编写，前端开发中一次性使用的简单脚本等
|
||
|
||
|
||
3.CSS中display样式中Flex布局的使用
|
||
|
||
Flex 弹性布局具有以下特点：
|
||
1>主轴与交叉轴：弹性容器具有主轴（main axis）和交叉轴（cross axis）。默认情况下，主轴是水平方向，交叉轴是垂直方向。
|
||
|
||
2>弹性容器：通过将父元素的 display 属性设置为 flex 或 inline-flex 来创建弹性容器。
|
||
子元素的弹性项目：弹性容器中的每个子元素都成为弹性项目。子元素可以指定各自在主轴和交叉轴上的大小、顺序以及对齐方式等。
|
||
|
||
3>主轴对齐：弹性项目可以在主轴上按照一定比例分配空间，也可以使用 justify-content 属性定义主轴的对齐方式。
|
||
|
||
4>交叉轴对齐：弹性项目可以在交叉轴上进行对齐，包括顶部对齐、底部对齐、居中对齐等，使用 align-items 属性定义交叉轴对齐方式。
|
||
|
||
5>换行与自动调整：可控制弹性项目是否换行，并且具备自动调整元素大小的能力。
|
||
|
||
弹性布局简化了网页布局的开发过程，提供了更灵活、响应式的布局方式。它适用于各种屏幕尺寸和设备类型，并能够快速适应不同的布局需求。
|
||
|
||
|
||
|
||
|
||
|