Vue2 的 Options API
在 Vue 2 中我们是如何组织代码的? 我们会在一个 vue 文件中 methods,computed,watch,data中等等定义属性和方法,共同处理页面逻辑,我们称这种方式为 Options API
。
Options 的缺陷 - 反复横跳
一个功能往往需要在不同的 vue 配置项中定义属性和方法,比较分散,需求简单还好,清晰明了;但是需求复杂之后,就会多出watch,computed,inject,provide等配置,这个 .vue 文件也会逐渐增大,且一个 methods 中可能包含 10-20 个方法,
你往往分不清哪个方法对应着哪个功能。
当维护过超过200行的 .vue 组件,新增或者修改一个需求,就需要分别在data,methods,computed里修改 ,滚动条反复上下移动,我称之为『反复横跳』 比如我们加个累加器的需求,这种写代码上下反复横条的感觉, 相信大家都懂的。
Option的缺陷:mixin 和 this
反复横跳的本质,在于功能的分块组织,以及代码量太大了,如果我们能把代码控制在一屏,自然就解决了,vue2 里的解决方案,是使用 mixin 来混合,比如我们抽离一个 counter.js。
这样确实拆分了代码,但是有一个贼严重的问题,就是不打开 counter.js,App.vue 里的 this上,count,add这些属性,是完全不知道从哪来的,你不知道是mixin,还是全局install,还是Vue.prototype.count
设置的,数据来源完全模糊,调试爽死你,这也是 option 的一个大问题,this是个黑盒,template 里写的 count 和 double,完全不知道从哪来的。
同时还会有 mixin 命名冲突的问题。
Vue3 中的 Composition API ( 组合式API )
Vue3 中的 Composition API
就是用来解决这个问题的:通过组合的方式,把零散在各个data,methods的代码,重新组合,一个功能的代码都放在一起维护,并且这些代码可以单独拆分成函数 。
在 Vue3 Composition API 中,我们的组件代码根据逻辑功能来组织的,一个功能所定义的所有 API 会放在一起(更加的高内聚,低耦合)。这样做即使项目很大,功能很多,我们都能快速的定位到这个功能所用到的所有 API,而不像 Vue2 Options API 中一个功能所用到的 API 都是分散的,需要改动功能,到处找 API 的过程是很费劲的。
因此,也就有了以下这张经典示例图: