Vue3 的组合式 API 优点是啥？

[KevinQi]

组合式 API 比选项式有啥优点？

感觉选项式组件代码结构更清晰啊。

[DonaidTrump]

卧槽， 点进来想了一会儿才反应过过来是 component 和 options 。
优点楼下总结吧

[implion]

和 TypeScript 更配

[huijiewei]

一个人想怎么写就怎么写

要是多个那 mixin ，你都不知道你的数据在哪个 mixin 被整过

[Megrax]

https://cn.vuejs.org/guide/extras/composition-api-faq.html#better-logic-reuse

[jrtzxh020]

更灵活更容易写出💩山代码

[wu67]

数据和逻辑可以写到附近. 而不是在 data 写数据, 在 methods 写逻辑, 当你的文件够大时, 你改一个东西, 要不停的翻页来来去去

[Zzzz77]

1. 当你的组件比较复杂的时候，options 的形式很难进行代码的拆分，容易写出上千行的巨型组件（ mixins 的缺点不多阐述了）。
2. 就“代码拆分难”这个点，除了容易产生巨型组件，还有“组件逻辑复用难”的问题。
3. 更好的 TypeScript 支持。

至于结构清晰这个点，仁者见仁。

[sdrpsps]

可以实现逻辑的拆分

[linxl]

官方的案例给人感觉是提高复用

[superedlimited]

让 vue 更容易学了，之前的 vue2.0 ，相比较于 react 真是太难了~

[vinsony]

@wu67 #6 我觉得这算是最没用的优点了，改 html 和 css 的时候还是得去翻

[MRG0]

除了更灵活，别的我没感觉出来

[wu67]

@vinsony 你这不是硬杠吗? vue2 改 html 和 css 不照样要翻来翻去? 现在组合式好歹把 js 部分的给调了, 改逻辑的时候不用那么频繁翻页

[mxT52CRuqR6o5]

组合优于继承的思想，不过我觉得，应用不复杂到一定程度，未必能体会到组合的优势
反倒是生命周期的那套设计可能更符合上古 jquery 时代的前端的直觉（不过组合式 API 里也有生命周期的概念，不像 react 那样完全抛弃了生命周期的概念，属于是介于两者中间的设计）
不过你要问我用啥我肯定是用组合式 API

[AV1]

选项式 API 按照 data 、methods 、生命周期、computed 、watch 划分区域。
组合式 API 则是鼓励开发者按照业务来划分区域。

选项式 API 写法会造成相同业务之间的数据、逻辑经常割裂开来，而且不易于复用。
组合式 API 目的就是解决这个问题，但是对开发者的要求也提高了。因为“业务”并不是很清晰的概念。
如果开发者技术能力不行，对业务了解不足，缺乏远见，就会写出比选项式 API 更混乱的代码。

[zglw2012]

可以将业务逻辑与 vue 框架分离
class AService{
state
method(){
// ...
}
}
对接到 vue 组件的时候，可以直接使用一个 reactive 就完成了逻辑的响应式绑定：
const aService = reactive(new AService())
在模板里，需要用 state 了，就是 aService.state ，需要用函数了，就 aService.method()

也就是说，用 vue 组合式 api ，一般的项目只用一个 reactive 就够了，再大一点的项目，加个 provide 和 inject 也够了。
如果两个业务逻辑互相有依赖，可以使用构造函数传，也可以在一个业务逻辑里增加个 setBService 的方法传。

配合 ts ，维护的时候在模板里直接 F12 就跳转到对应的 ts 实现了，简直不要太快。

[asen001]

好处是更灵活，可以写的花里胡哨的各种封装。但是如果完全不考虑封装和复用，按着 options api 的风格写大坨的 setup 函数，很容易就成屎山了。
看过同事两千多行的 vue 文件，光 setup 函数 return 就有七八十行，恐怖至极

[Anivial]

简单来说就是更符合编程习惯了，变量和函数的命名是需要用到时定义，而不会出现一堆变量都在 data 里每次查看引用与定义都像是坐过山车。

[optional]

可以按照功能组织代码。
最简单的例子，onMounted 可以调用多次，不同的逻辑卸载不同的代码块里，甚至封装成一个功能插件。

[xiaoxiaoming01]

打 Vue 教徒的脸（他们经常攻击 react ，认为写法灵活是一种罪）

[coolair]

感觉没啥优点，更乱了，我还是喜欢 Vue2 那套写法，简洁干净多了……
可能我比较菜，哈哈。

[yuekcc]

代码组织方式更接近一般 js 。当然要配合 <script setup> 块才好用。写 setup() {} 的话，还没有 option api 好使。

[rocktodog8080]

和 react hooks 一样 最大的优点就是逻辑复用 看看各种流行的 hooks 库就明白了

[darknoll]

比 2 灵活，我觉得还是 3 好一点

[yuyanstation528]

对逻辑复用以及插件的编写更友善，但如果你是复杂度不高的小项目，或者整个项目只有一两个人维护，选项式反而横清晰，vue3 里你也可以继续用选项式

[shakukansp]

举个简单的例子，一个页面三个表格，每个表格 3 个 modal 弹窗
用 options api 写 data 和 methods 里面会写成什么样感受一下

[ruoxie]

https://juejin.cn/post/7139497477086019621 可以这样分层，维护起来巨爽，避免各种妖魔鬼怪的代码出现

[ruoxie]

@rocktodog8080 业务代码哪来那么多复用，vueuse 就够用了，用了那么久感觉最大的好处就是逻辑和 ui 可以分离，可以引入更多的架构的思想去规范项目整体框架

[zjsxwc]

组合式 API: 单纯的只是为了能够把相关联的逻辑放在一起。
选项式 API: 前提是前端开发者没有工程化意识的情况下！！！会把逻辑写的很分散。

总结，如果是有经验的前端开发者，会通过依赖注入等方式把选项式 API 写的很有条例，能实现组合式 API 一样把相关联的逻辑放在一起，但由于现实情况是太多的新手前端写的太乱，能跑就行，于是推出了组合式 API 来规范新手前端。

[coldmonkeybit]

我觉得是更接近原生，vue 的 runtime 就像所有其他第三方库一样给你提供一些 api 而已，减少了正在使用框架的感觉让我觉得挺爽的

[connection]

抽象逻辑的复用

[wangtian2020]

[this.] 前缀写腻了？现在可以试着改用 [.value] 后缀了！