# 一、为什么选择CompositionAPI

# Vue2的局限性

• 组件逻辑膨胀导致的可读性变差
• 无法跨组件重用代码
• Vue2对TS的支持有限

在传统的OptionsAPI中我们需要将逻辑分散到以下六个部分

OptionsAPI

• components
• props
• data
• computed
• methods
• lifecycle methods

# 如何使用CompositionAPI解决问题

最佳的解决方法是将逻辑聚合就可以很好的代码可读性。

这就是我们的CompositionAPI语法能够实现的功能。CompositionAPI是一个完全可选的语法与原来的OptionAPI并没有冲突之处。他可以让我们将相同功能的代码组织在一起，而不需要散落到optionsAPI的各个角落

# 代码重用方法PK

Vue2中的跨组件重用代码，我们大概会有四个选择

1. Mixin - 混入

• 代码混入其实就是设计模式中的混合模式，缺点也非常明显。
• 可以理解为多重继承，简单的说就是一个人如何有两个父亲

缺点

• 无法避免属性名冲突
• 继承关系不清晰

2. Mixin Factory - 混入工厂

返回一个

✅代码重用方便

✅继承关系清洗

3. ScopeSlots - 作用域插槽

❌可读性不高

❌配置复杂 - 需要再模板中进行配置

❌性能低 - 每个插槽相当于一个实例

4. CompositionApi - 复合API

✅代码量少

✅没有引入新的语法，只是单纯函数

✅异常灵活

✅工具语法提示友好 - 因为是单纯函数所以 很容易实现语法提示、自动补偿

# 二、setup & ref

# 使用CompositionAPI理由

✅更好的Typescript支持

✅在复杂功能组件中可以实现根据特性组织代码 - 代码内聚性👍 比如： 排序和搜索逻辑内聚

✅组件间代码复用

# setup是什么

• 在以下方法前执行：
  • Components
  • Props
  • Data
  • Methods
  • Computed Properties
  • Lifecycle methods
• 可以不在使用难于理解的this
• 有两个可选参数
  • props - 属性 (响应式对象 且 可以监听(watch))

import {watch} from "vue"
export defalut {
	props: {
		name: String
	},
	setup(props) {
		watch(() => {
			console.log(props.name)
		})
	}
}

• context 上下文对象 - 用于代替以前的this方法可以访问的属性

setup (props,context) {
	const {attrs,slots,parent,root,emit} = context
}

# ref是什么

对基本数据类型数据进行装箱操作使得成为一个响应式对象，可以跟踪数据