>[success] # Option API VS Composition API ~~~ 1.'3.x' 之前都是探讨关于'2.x' 和'3.x' 细节上的改动，现在要探讨的是整个'3.x' 最核心的变化 提供了'Composition Api' ~~~ >[info] ## 什么是Option API ~~~ 1.之前在'2.x' 系列我们的写法可以成为'Option API'简单理解根据配置项去按照规则将对应代码放到 对应的配置项中,对应的产生了三个问题 1.1.随着组件变得更大的可读性变得越来越困难尤其大型组件 1.2.不利于代码重用，即使有'Mixins'方案整体也有一些问题 1.3.Vue 2提供了有限的TypeScript支持 ~~~ >[danger] ##### 大型组件可能难以阅读和维护 ~~~ 1.我们的功能包含的代码需要将所有组件选项(data,method,computed,声明周期等)之间进行拆分。 就像下图一样'从而使我们的组件更难以阅读和解析哪个功能代码与哪个功能一起使用' ~~~ * [图片来自 ](https://juejin.cn/post/6890545920883032071)  * 官方图片  >[danger] ##### 组件之间重用 ~~~ 1.'2.x' 也提供了三种重用解决方案'Mixins','Mixin工厂','作用域插槽' ~~~ >[info] ## 为什么出现Composition Api ~~~ 1.'composition api' 就可以让同一个功能的代码放到一起，查看修改的时候不用一个文件到处跳 2.'composition api' 优点 2.1.'Composition API' 是根据逻辑相关性组织代码的，提高可读性和可维护性 2.2基于函数组合的 API 更好的重用逻辑代码（在vue2 Options API中通过Mixins重用逻辑代码， 容易发生命名冲突且关系不清） ~~~ >[danger] ##### Composition Api 解决大型组件维护问题 ~~~ 1.如果将功能代码保持在一起这样代码'可读性、可维护性'，'3.x' 提供了新的api'setup',这是一个可选的 也就是说'3.x' 是同时支持'Composition Api ' 和'Option API' 两种编写习惯的 2.如果将代码都构建在'setup'中，是否会出现一个庞大的'setup' 冗杂这各种逻辑在里面，这个问题不用担心 如图二给出的方案'会将功能分组为可通过设置方法调用的组合功能' ~~~ * [图片来自 ](https://juejin.cn/post/6890545920883032071)  * [图二来自](https://www.vuemastery.com/courses/vue-3-essentials/why-the-composition-api)  >[info] ## 3.x 我应该用那种来写 ~~~ 1.官方的课程也给了建议，如果你满足下面其中一点说明你要使用setup了 1.1.您需要最佳的TypeScript支持。 1.2.组件太大，需要按功能进行组织。 1.3.需要在其他组件之间重用代码。 1.4.您和您的团队更喜欢替代语法。 ~~~ >[danger] ##### 内容来源参考 [vuemastery](https://www.vuemastery.com/courses/vue-3-essentials/why-the-composition-api) >[danger] ##### 更详细内容 [尤雨溪在乎的文章](https://zhuanlan.zhihu.com/p/68477600)