Open PaulChess opened 2 years ago
首先,以前 vue2 里面的那些选项比如 data
method
watch
等等都被整合到了 setup
函数中,这样把它们放在同一个上下文里更有利于 typescript 类型推导。
这里举一个切换白天、黑夜模式的例子,我们可以看到左右两侧一一对应。
有些人可能会有疑问了,从代码上看也没啥明显区别啊? 我们想想,Vue2 的复用单元是组件,是template, script, style 的组合,如果我们在跨项目或者跨团队复用的时候由于dom或者样式不同无法直接复用组件,仅仅需要这一段核心逻辑的时候该怎么办呢? 有些人可能会说,用 mixin啊,但是大家想想 mixin 有什么问题? 来源不清晰,比如一个页面里注册了多个 mixin 以后,我可以任意调用某个 mixin 中的 data 或者是 method, 到时候溯源的时候找都找不到,只能全局搜索。
所以, composition-api的作用:
这个案例里面用了 composition-api 以后,只对外部暴露出了最核心的状态以及修改状态的方法,至于其他的数据变更的逻辑开发无需关心,这部分一定是最通用的逻辑。
缺点: 非常考验开发对功能的抽象能力,抽离方式不当的话反而会适得其反,降低扩展性。所以 vue3 一方面给前端开发带来了更高的灵活性,也对开发人员提出了更高的软件设计层面的要求。
使用composition-api 的误区: 没有了这些option的限制,我可以随便怎么写了 ❎ composition-api 最重要的的目的是拆分功能并做功能组合,而不是说一个组件 setup 下面密密麻麻写了 2000 行代码,等过两年 vue3 的实践更加成熟了,接手的小伙伴看到这种代码肯定是一顿狂喷啊~
composition-api 得益于拆分出来的 @vue/reactive 这个包,使得响应式的逻辑可以和 ui 分离,而且与框架无关,也就是说,它提供的仅仅是关于数据响应式的一套解决方案。 useFetch useLocalStorage useEventListener
这一块的实战大概 4 页 再带大家看一下之前 Calendar 和 CalendarTab 两个组件使用 Composition API 分明的对比,直观感受。
目录加一页 剩余干货