Vue3自定义Hooks定义:
个人理解:一些可复用的方法像钩子一样挂着,可以随时被引入和调用以实现高内聚低耦合的目标,应该都能算是hook;
为什么Vue3要用自定义Hook?:
结论:就是为了让Compoosition Api
更好用更丰满,让写Vue3更畅快!像写诗一样写代码!
其实这个问题更深意义是为什么Vue3比Vue2更好!无外呼性能大幅度提升,其实编码体验也是Vue3的优点**Composition Api
的引入(解决Option Api在代码量大的情况下的强耦合)** 让开发者有更好的开发体验。
个人碎碎念:但是这些所谓的提高开发体验都是需要开发者不断学习养成编码好习惯,同样是Vue3写Compoosition Api有的人就能写得和诗一样,有的人却能写得像💩一样(衷心希望每个开发者都有一颗对技术热衷的心,不要为了开发而开发,前人写翔让后人尝!抱歉最近因为维护老项目太多感慨)
写Vue3请摆脱Vue2无脑this的思想:
写Vue2中很多同学养成了
Option Api
无脑this的习惯,来到Vue3
的Composition Api
还是习惯性想用this,更有人为了写this不惜引入getCurrentInstance
!这大可不必!
Composition Api
的优点之一就是摆脱无脑this导致的强耦合,功能之间互相this,变量和方法在各个方法混杂,无处不在的this是强耦合的,虽然方便,但是碎片化的option api 后期维护是麻烦的。
我相信写Vue2
的同学,一定深有感触,一个组件下定义大量变和大量方法,方法嵌套方法,方法之间互相共享变量,维护这样的代码,看似容易理解的Option Api
写法,我们需要在methos、data、template
之间来回切,Option Api
这种写法,代码量和功能小巧时是十分简单明了的,但是代码量一多,功能一复杂,我相信review代码的时候头都痛。
相对的Composition Api
在功能复杂、代码量巨大的组件下,我们配合自定义Hooks,将代码通过功能分块写,响应变量和方法在一起定义和调用,这样后期我们改功能A只需要关注功能A块下的代码,不会像Vue2在Option Api
需要同时关注methos和data。。。。。
几张动图再来复习一遍 Composition Api
好!
谢谢
大帅老猿
老师做的动图,Composition Api VS Option Api
的优缺点十分明了展示在了动画上!
Option Api
代码量少还好,代码量多容易导致高耦合!
说明:上面是Vue2 Option Api
的写法,一个组件下含有data 、methos、computed、watch
,同一个功能需要分开写在这些函数上,如果代码量少,那看起来似乎十分明了清晰。一旦代码量大功能复杂,各个功能分开写,维护的时候data 、methos、computed、watch
都需要来回切,反而显得过于分散,又高度耦合。
Composition Api
解耦Vue2 Option Api
实现低耦合高内聚
说明:如果是Composition Api
在功能复杂、代码量巨大的组件下,我们配合自定义Hook,将代码按功能分块写,变量和方法在一起定义和调用,比如A功能下集成了响应式变量和方法,我们后期维护只需要改动A功能模块下的代码,不会像Vue2在Option Api
需要同时关注逻辑分散的methos和data。
所以自定义Hook的写Vue3必须掌握的!它无不体现Vue3 Composition Api 低耦合高内聚的思想! 笔者在看了官方文档和开源的admin模板都是大量使用自定义Hooks的!
大胆定义一下Vue3的自定义Hook:
虽然官方没有明确指明或定义什么是自定义Hooks,但是却无处不在用;
以函数形式抽离一些可复用的方法像钩子一样挂着,随时可以引入和调用,实现高内聚低耦合的目标;
-
将可复用功能抽离为外部JS文件
-
函数名/文件名以use开头,形如:useXX
-
引用时将响应式变量或者方法显式解构暴露出来如:
const {nameRef,Fn} = useXX()
(在setup函数解构出自定义hooks的变量和方法)
实例:
简单的加减法计算,将加法和减法抽离为2个自定义Hooks,并且相互传递响应式数据
- 加法功能-Hook
import {
ref, watch } from 'vue';
const useAdd= ({
num1, num2 }) =>{
const addNum = ref(0)
watch([num1, num2], ([num1, num2]) => {
addFn(num1, num2)
})
const addFn = (num1, num2)