optionsAPi的弊端
- 在vue2中我们编写组件的方式是optionsAPI
例如:data定义的数据、methods定义的方法、computed中定义的计算属性、watch中监听属性的改变,还包括生命周期钩子
弊端
在我们实现某些功能的时候,例如写一个计数器
往往我们需要定义methods,其中定义一个+1/-1的函数、需要定义data中的counter数据、监听counter的改变。
当我们的代码逻辑变得很庞大的时候,逻辑就会变得不清晰,且代码量会变大很大,定义的方法和数据不连贯,使得代码的阅读和理解会变得很困难。
CompositionAPI
我们要使用Composition API时我们需要在vue组件中使用setup函数。
setup函数就是用来替代之前所编写的大部分选项。包括methods、computed、data、watch、生命周期等
setup函数的参数
1.props
props非常好理解,它其实就是父组件传递过来的属性会被放到props对象中,我们在setup中如果需要使用,那么就可以直接通过props参数获取。
1 | <home message="父组件中的message"/> |
子组件中接收父组件传过来的messsage并指定类型和是否必须传过来。否则会报一个warning。
1 | props: { |
2.context
context也被称之为setupcontext,他包含三个属性:
- attrs
所有的非prop的attribute - solts
父组件传递过来的插槽 - emit
当我们组件内部需要发出事件时会用到emit(因为我们不能访问this,所以不可以通过 this.$emit发出事件)
setup的返回值
返回值是一个对象
1 | let counter = 100; |
setup中不可以使用this,是因为在创建setup是压根就没有绑定this
reactiveAPI
- 引入reactive:
import { reactive } from "vue";
- reactive的使用将counter定义在reactive中,这样会使counter变成响应式。使得我们在increment中修改counter时,我们在界面中所展示的counter的值也会跟着改变
1
2
3
4
5
6
7
8
9
10
11
12
13
14reactive的使用
const state = reactive({
counter: 100,
})
const increment = () => {
state.counter++;
console.log(state.counter);
}
return {
state,
increment,
}
reactive API对传入的类型是有限制的,要求我们传入的是一个对象或者数组。否则会报一个警告。
refAPI
- refAPI的引入
import { ref } from "vue";
ref APT会返回一个可变的响应式对象,该对象作为一个响应式的引用维护着他内部的值。他内部的值是在ref的value中被维护的。
ref的自动解包
1.当我们在template中使用ref对象的时候,他会自动进行包,不需要我们在ref对象后面添加.value
2.此时这里的counter == counter.value
这里的解包是浅层解包
- 如果外层嵌套的是一个reactive的对象时,可以自动解包
- 如果外层对象是一个普通的对象的时候,是不能自动解包的
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15/* couter变成了一个ref的可响应式的引用(对象) */
//此时的counter可以说是一个对象
let counter = ref(100);
//在编写逻辑代码的时候我们要拿到counter(对象)的值的时候是需要加.value的
//在逻辑代码中或者说在setup这个函数中是没有进行自动解包的过程
const increment = () => {
counter.value++;
console.log(counter.value);
}
return {
counter,
increment,
}
readonly(只读/不可改写)
在开发中常见的readonly方法会传入三个类型的参数:
类型一:普通对象;
类型二:reactive返回的对象;
类型三:ref的对象;
readonly的使用
1 | // 1.普通对象 |