这是一个创建于 601 天前的主题，其中的信息可能已经有所发展或是发生改变。
组合式 API 比选项式有啥优点？
感觉选项式组件代码结构更清晰啊。
 |
1
tulongtou 2023-04-20 16:07:00 +08:00
卧槽， 点进来想了一会儿才反应过过来是 component 和 options 。
优点楼下总结吧 |
 |
2
implion 2023-04-20 16:07:03 +08:00
和 TypeScript 更配
|
 |
3
huijiewei 2023-04-20 16:09:27 +08:00  1
一个人想怎么写就怎么写
要是多个那 mixin ，你都不知道你的数据在哪个 mixin 被整过 |
 |
4
Megrax 2023-04-20 16:10:59 +08:00
|
 |
5
jrtzxh020 2023-04-20 16:13:02 +08:00
更灵活更容易写出💩山代码
|
 |
6
wu67 2023-04-20 16:16:00 +08:00
数据和逻辑可以写到附近. 而不是在 data 写数据, 在 methods 写逻辑, 当你的文件够大时, 你改一个东西, 要不停的翻页来来去去
|
 |
7
Zzzz77 2023-04-20 16:19:46 +08:00 1
1. 当你的组件比较复杂的时候，options 的形式很难进行代码的拆分，容易写出上千行的巨型组件（ mixins 的缺点不多阐述了）。
2. 就“代码拆分难”这个点，除了容易产生巨型组件，还有“组件逻辑复用难”的问题。 3. 更好的 TypeScript 支持。 至于结构清晰这个点，仁者见仁。 |
 |
8
sdrpsps 2023-04-20 16:20:20 +08:00
可以实现逻辑的拆分
|
 |
9
linxl 2023-04-20 16:22:03 +08:00
官方的案例给人感觉是提高复用
|
 |
10
superedlimited 2023-04-20 16:23:14 +08:00
让 vue 更容易学了，之前的 vue2.0 ，相比较于 react 真是太难了~
|
 |
12
MRG0 2023-04-20 16:29:28 +08:00
除了更灵活，别的我没感觉出来
|
|
13
wu67 2023-04-20 16:31:48 +08:00
@vinsony 你这不是硬杠吗? vue2 改 html 和 css 不照样要翻来翻去? 现在组合式好歹把 js 部分的给调了, 改逻辑的时候不用那么频繁翻页
|
 |
14
mxT52CRuqR6o5 2023-04-20 16:36:51 +08:00
组合优于继承的思想，不过我觉得，应用不复杂到一定程度，未必能体会到组合的优势
反倒是生命周期的那套设计可能更符合上古 jquery 时代的前端的直觉（不过组合式 API 里也有生命周期的概念，不像 react 那样完全抛弃了生命周期的概念，属于是介于两者中间的设计） 不过你要问我用啥我肯定是用组合式 API |
 |
15
DOLLOR 2023-04-20 16:53:34 +08:00 1
选项式 API 按照 data 、methods 、生命周期、computed 、watch 划分区域。
组合式 API 则是鼓励开发者按照业务来划分区域。 选项式 API 写法会造成相同业务之间的数据、逻辑经常割裂开来，而且不易于复用。 组合式 API 目的就是解决这个问题，但是对开发者的要求也提高了。因为“业务”并不是很清晰的概念。 如果开发者技术能力不行，对业务了解不足，缺乏远见，就会写出比选项式 API 更混乱的代码。 |
 |
16
zglw2012 2023-04-20 17:31:25 +08:00
可以将业务逻辑与 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 实现了，简直不要太快。 |
 |
17
asen001 2023-04-20 17:49:52 +08:00
好处是更灵活，可以写的花里胡哨的各种封装。但是如果完全不考虑封装和复用，按着 options api 的风格写大坨的 setup 函数，很容易就成屎山了。
看过同事两千多行的 vue 文件，光 setup 函数 return 就有七八十行，恐怖至极 |
 |
18
Anivial 2023-04-20 18:13:48 +08:00 3
简单来说就是更符合编程习惯了，变量和函数的命名是需要用到时定义，而不会出现一堆变量都在 data 里每次查看引用与定义都像是坐过山车。
|
 |
19
optional 2023-04-20 19:46:03 +08:00 1
可以按照功能组织代码。
最简单的例子，onMounted 可以调用多次，不同的逻辑卸载不同的代码块里，甚至封装成一个功能插件。 |
 |
20
xiaoxiaoming01 2023-04-20 20:55:55 +08:00 1
打 Vue 教徒的脸（他们经常攻击 react ，认为写法灵活是一种罪）
|
 |
21
coolair 2023-04-20 22:54:33 +08:00
感觉没啥优点，更乱了，我还是喜欢 Vue2 那套写法，简洁干净多了……
可能我比较菜，哈哈。 |
 |
22
yuekcc 2023-04-20 22:56:26 +08:00
代码组织方式更接近一般 js 。当然要配合 <script setup> 块才好用。写 setup() {} 的话，还没有 option api 好使。
|
 |
23
rocktodog8080 2023-04-20 23:01:28 +08:00 1
和 react hooks 一样 最大的优点就是逻辑复用 看看各种流行的 hooks 库就明白了
|
 |
24
darknoll 2023-04-20 23:20:07 +08:00
比 2 灵活，我觉得还是 3 好一点
|
 |
25
yuyanstation528 2023-04-20 23:21:30 +08:00 via iPhone
对逻辑复用以及插件的编写更友善，但如果你是复杂度不高的小项目，或者整个项目只有一两个人维护，选项式反而横清晰，vue3 里你也可以继续用选项式
|
 |
26
shakukansp 2023-04-21 00:10:29 +08:00
举个简单的例子，一个页面三个表格，每个表格 3 个 modal 弹窗
用 options api 写 data 和 methods 里面会写成什么样感受一下 |
 |
27
ruoxie 2023-04-21 00:41:28 +08:00 via iPhone
https://juejin.cn/post/7139497477086019621 可以这样分层，维护起来巨爽，避免各种妖魔鬼怪的代码出现
|
|
28
ruoxie 2023-04-21 00:52:53 +08:00 via iPhone
@rocktodog8080 业务代码哪来那么多复用，vueuse 就够用了，用了那么久感觉最大的好处就是逻辑和 ui 可以分离，可以引入更多的架构的思想去规范项目整体框架
|
 |
29
zjsxwc 2023-04-21 09:28:10 +08:00
组合式 API: 单纯的只是为了能够把相关联的逻辑放在一起。
选项式 API: 前提是前端开发者没有工程化意识的情况下！！！会把逻辑写的很分散。 总结，如果是有经验的前端开发者，会通过依赖注入等方式把选项式 API 写的很有条例，能实现组合式 API 一样把相关联的逻辑放在一起，但由于现实情况是太多的新手前端写的太乱，能跑就行，于是推出了组合式 API 来规范新手前端。 |
 |
30
coldmonkeybit 2023-04-21 09:36:40 +08:00
我觉得是更接近原生，vue 的 runtime 就像所有其他第三方库一样给你提供一些 api 而已，减少了正在使用框架的感觉让我觉得挺爽的
|
 |
31
connection 2023-04-21 15:14:27 +08:00
抽象逻辑的复用
|
 |
32
wangtian2020 2023-04-21 17:11:52 +08:00
[this.] 前缀写腻了？现在可以试着改用 [.value] 后缀了！
|
Select Language