听说现在各个厂都在调研vue3.0，身为vue系的在下感觉再不学习一番又要找不到工作了，毕竟现在北京卷的厉害~
所以在求生欲的驱使下，我还是奋力撸了一把vue3，并在项目中实际使用了下，得出下面心得：
vue3.0变化的最大部分还是Composition-api，真正将以前vue组件的逻辑与渲染拆分开来，达到最大程度逻辑复用。
—— 资深较真儿工程师 Yubble
认识组合API：
要聊Composition-api的话，还是得说下它的前身Options-API。
请看下下面这段代码：
“methods, computed, watch” 标准的vue2.0写法，这种vue规范的格式，就被称为Options-API。再看下面这段代码：
同样功能的代码，并不拘泥于格式，而是用户想用vue中的哪个功能按需选取，弱化了框架的束缚感，此处与React Hooks的设计思路如出一辙，网上看到很多人都在说vue3是在抄React，人家尤大都说了是借鉴。
为什么要用组合API：
在下在开始撸Composition-API时也是一脑袋问号，如果说功能复用的话，vue的组件化就可以达到效果呀，为什么还要搞个这？
看到网上各种评论与吐槽之后顿然悟了，年轻了，一直没发现它的美是因为业务‘量太少了’。所以我们都写在一个Options-API就行。
还是看在下这真实而悲惨的实例吧：
比如我现在有一个猫舍网站，随着这个网站量的增长，功能也变的庞大，其中有一个组件，它需要有以下功能：
1、显示库存的猫咪数量
2、筛选出幼年猫和成年猫
3、找出被用户预定的猫咪
4、给某只猫咪下架
如果是Options-API的话，这个代码怎么写：
可以看到上面是标准的Vue2.0写法，以上功能都能实现没毛病，但是随着业务增长，代码量越来越大，这个组件就衍生了两个问题，单个文件中代码过长导致可读性差，相似功能无法抽离供其他组件复用。
那么有客官甲就要问了，现在都是esm模块化了，为什么功能不能单独写个.js文件引进来？
写成.js引进来当然可以，但是脱离了Options-API的标准，就失去了vue提供的双向绑定类能力，以及计算属性，观察者等方法。
这时有客官乙问了，Vue提供的mixins不是解决了功能无法复用的问题吗？同时还保持了之前的Options-API的标准格式。
不说还好，一提这个mixins我就上火，确实是保持了Options-API的规范，让vue效果的功能得以复用，但是用过的同学都知道，这玩意儿伤害太大，首先state中的数据来源无法定位，贸然修改就会影响到父级或是其他使用到state的组件，且引用mixins中的方法不方便定义来源，如果一个组件中引入的mixins较多，那么就很难定位到这个方法是哪个mixins中引入的，如果在mixins中嵌套其他mixins，就炸了。所以我的观点，在开发时还是要慎用mixins这个方法的。
结论：
组合API的出现可以干掉mixins，让单独的.js文件也能具备vue提供的双向绑定，生命周期等能力。
组合API怎么用：
就着刚才那个实例说哈，我们已经看到了如果用Options-API的方式开发所有的逻辑都会挤到一个组件中，这时为了代码质量，架构合理性，我们需要将功能单独抽离出来，形成下面这种结构：
理想的结构中，‘找出客户预定猫咪’、‘获取所有猫咪’、‘筛选猫咪类型’应该是三个独立的功能模块。在Composition-API中我们就很容易可以实现它了。
step1：把找出客户预定猫咪提取出来
step2：把获取所有猫咪功能提取出来
step3：把筛选猫咪类型功能提取出来
step4：在组件中引入这三个功能
整体修改之后，视图层还是用的之前的html没有变化，但是逻辑层变得层次分明，所有操作到的参数有迹可循，功能相互独立。这种变化在大业务量，重代码项目中的收益是十分明显的。
心得体会：
并不是有了组合API之后，组件化的写法就不香了，如果是小型项目，Options-API的写法还是能保证标准化规范的。且Composition-API这种写法的作用是复用/抽取Vue能力的业务逻辑，如果功能相互依赖性强的话，写在一个Options-API中还是很合理的。
聊闲白儿：
又到了闲聊天的时候，最近在下面了几场试，真心觉得现在整体环境是真的卷呐，面试各种算法题招呼，框架源码手写，前端银儿过的还是挺煎熬的呀~
不过面到的大厂基本上也都以React为主，可以理解，毕竟业务量在这摆着，用React写业务模块拆分香很多，并且JSX语法也是vue所不可及的，各有所长。所以在下也是在业余时间写写React，并总结它与Vue的对比优劣，希望能让自己更有竞争力一些。
最后祝各位互联网同学新的一年都找到自己心仪的工作，为之奋斗吧~
