作者：京东物流 吴云阔
Vue3已经正式发布了一段时间了，各种生态已经成熟。最近使用taro+vue3重构冷链的小程序，经过了一段时间的开发和使用，有了一些自己的思考。
总的来说，Vue3无论是在底层原理还是在实际开发过程中，都有了很大的进步。
从源码层面来说，使用Proxy代替Object.defineProperty的API，一个是代理的对象，一个是递归监控的属性，从而在性能上有了很大的进步，并且，也解决了对象动态属性增加、数组改变监听上的缺陷；对diff算法进行优化，增加了静态标记，大大提高了Vue的执行效率；还有静态提升、事件监听缓存等一系列提升效率的手段。
从应用层面来说，主要的改变是将option API改成了composition API（组合式API），在业务中抛弃data、methods、生命周期函数隔离开的开发方式，使代码相对于业务有更强的聚合性，在代码开发、代码阅读、代码维护方面对于开发者都是更加友好。
对于typescript有了更好的支持，我们知道，对于大型的前端项目来说，使用typescript的类型校验，能使前端项目有更强的健壮性，这也使得Vue3对于大型项目的开发提供了更强的质量保证。
所谓的组合式API，将Vue2中的data、methods、生命周期、数据监听等option，都封装成钩子函数，然后组合到setup函数中，其核心就在于setup函数。setup函数存在的意义，就是为了使用这些新增的组合式API，并且这些API只能在setup函数中使用。
setup函数执行的时机是，props初始化之后，beforeCreate函数执行之前，所以在执行setup时，还没有初始化Vue实例，因此在setup中不能使用this对象。setup函数的返回值会被注入到Vue实例中，供Vue组件使用，所以任何数据想在Vue组件的模板中使用，必须在setup函数中return出去。
组合式API的组合，体现在两个层面。第一层的意思是，将某一业务相关数据和处理逻辑放到一起，这是一种关注点的聚合，更方便我们编写代码、处理业务逻辑，并且能更聚焦业务逻辑，更方便我们看代码。第二层面的意思，当某个组件的业务逻辑足够复杂，setup中的代码足够大的情况下，我们可以在setup内部，进一步提取相关的一块业务，使代码逻辑更加清晰，做到了进一步的聚合作用。
如下面代码所示，将业务代码块A抽出来，则代码块A中return出来的数据就可以在组件中使用：
// 组件
import functionA from 'A'
export default defineComponent({
name: 'componentName',
setup() {
...functionA()
}
})
// 代码块A
export default () => {
return {
a: 1
}
}
在Vue3中响应式API，主要体现在ref和reactive两个函数。对于响应式API，想说两个问题，第一个是为什么要增加响应式API，第二个是响应式API函数ref和reactive的异同点。
在Vue2中所有数据都写在data的option中，data中的数据都是响应式的，这样产生的一个问题是，有些常量数据本身不需要监听，从而造成了资源的浪费。所以在Vue3中增加了响应式API，只需要对需要动态更新dom的数据进行响应式，不需要动态更新dom的数据不进行响应式处理，从很大程度上节省了资源。这里我觉得需要注意的是，写代码的时候一定要仔细思考一下，哪些数据需要进行响应式绑定，哪些数据不需要进行响应式绑定，而不是一股脑的全给绑定上，这样即使代码逻辑不能很清晰易懂，并且也会影响执行效率（写惯了Vue2的同学需要注意）。
在了解了为什么要增加响应式API后，我们发现Vue3提供了两个响应式API函数，ref和reactive。为什么会提供两个API呢？ 一个不就可以了吗？那么这两个API之间的区别是什么呢？
在使用层面，ref绑定的数据，需要使用[data].value进行数据更改。而reactive绑定的数据需要使用[data].[prpoerty]的方式进行数据更改。在使用场景方面，一般的，单个的普通数据，我们使用ref来定义响应式。而复杂数据，如：表单数据对象、某一模块的一组数据等，使用reactive来定义响应式。
那么，对象是不是必须用reactive来定义呢？ 其实不是的，都可以。官方说法是：可以根据自身习惯使用不同的API。其实，我觉得，他们是有各自的使用场景的，ref更强调的是数据Value的改变，reactive更强调的是数据中某一属性的改变。
当 Javascript 项目达到一定体积时，将代码分成模块会更易于管理。但是，当这样做时，我们最终可能会导入实际上未使用的代码。Tree Shaking 是一种通过消除最终文件中未使用的代码来优化体积的方法。
Vue3使用了tree shaking的方法，将组件以及其所有的生命周期函数等方法进行分开，如果在组件中使用的代码将不会出现在最终的打包文件中，如此，会减少大大Vue3项目的打包体积。由此造成的一个结果就是，使用方法的不同。
4.1 生命周期函数的使用方法
import { defineComponent, ref, onMounted } from 'vue';export default defineComponent({name: 'Gift',setup() {const counter = ref(0);onMounted(() => {// 处理业务，一般进行数据请求})return {counter}}})import { useStore } from "vuex";import { defineComponent, ref, computed } from 'vue';export default defineComponent({name: 'Gift',setup() {const counter = ref(0);const store = useStore();const storeData = computed(() => store); // 配合computed，获取store的值。return {counter,storeData}}})import { useStore } from "vuex";import { useRouter } from "vue-router";import { defineComponent, ref, computed } from 'vue';export default defineComponent({name: 'Gift',setup() {const counter = ref(0);const router = useRouter();const onClick = () => {router.push({ name: "AddGift" });}return {counter,onClick}}})这一部分是关于Ts的内容，不过它与Vue3的开发息息相关。Vue3整体是使用Ts写的，因此，开发Vue3的项目需要使用Ts，所以，我们还是要了解TS的。
关于Ts的使用这里就不在细说了，在这里想说的的是，在实际业务场景中是如何组织Ts代码的。通过对TS的大量使用，我的一个体会是：Ts的核心思维是先关注数据结构，在根据数据结构进行页面开发。而以前的前端开发模式是，先写页面，然后再关注数据。
比如说，我们要开发一个页面，我们可能需要先定义一些interface。开发页面的时候我们要关注：页面数据的interface、接口返回数据的类型、请求参数的类型等等。
下面是开发一个列表页面的例子：
// 这是列表中每一项的数据类型
interface IDataItem {
id: string | number;
name: string;
desc: string;
[key: string]: any;
}
// 接口返回值类型， 一般来说，我们不确定接口返回的数据的类型，因此使用泛型
interface IRes<T> {
code: number;
msg: string;
data: T
}
// 口返回数据类型定义
interface IDataInfo {
list: Array<IDataItem>;
pageNum: number;
pageSize: number;
total: number;
}
// 请求
export const getDatalist = (
params: Record<string, any>
): Promise<IRes<IDataInfo>> => {
return Http.get("/api/data/list", params);
};
如上面代码，当我们的interface定义完成后，我们的页面数据基本都已清楚，直接写页面就会清晰很多，且出错概率会大大降低。
距离Vue 3.0正式发布已经过去一段时间了，2月7日Vue团队正式宣布Vue 3正式成为新的默认版本。最近接触的新项目也使用Vue 3.0来开发，因此有必要对它进行一波总结和学习。