Alova的简单使用心得
传统请求库的痛点
传统请求库(如 axios
或浏览器的 fetch API
)专注于请求本身,这一点上它们的职责其实很专注,在请求这一功能上已经做得挺不错了;不过实际业务和项目中跟请求相关的一些常用的功能,这种请求库通常不会提供,虽说我们可以根据自身业务需求自己抽象出一些常用的功能,形成自己的请求策略库或者类似的工具,但偷懒是人之本性🙈(其实也是为了避免重复造轮子)。
常见的一些请求策略
仔细回想一下我们在项目中围绕着请求这一动作本身,会衍生出哪些常见的需求?
Loading状态
在诸如获取列表,提交表单这种业务场景下,页面中基本上都需要一个提示用户正在进行的 loading
状态,这种 loading
状态就是跟请求这一动作强相关的;虽然实际业务代码中,这么一种 loading
状态的修改就是一两行代码的事情,比如:
1 | // ... |
中止请求
在某些业务场景中,不可避免的会出现频繁触发请求的情况,而通常只需要对最后一次请求进行有效响应,因此就需要对之前已经发出的请求进行手动中止;传统的请求库一般都是需要手动创建一个AbortController,给到具体的请求,然后基于 AbortController
进行中止操作,如:
1 | const controller = new AbortController(); |
超时重试请求
顾名思义,在某些业务场景下需要对一些超时的接口进行多次的重试,以便提高业务可靠性;这种需求一般可以通过在请求的错误回调中识别出是超时来发起重试,其实axios也有相关的 retry
插件——axios-retry - npm;
请求结果缓存
对于某些不太变化的接口数据,或者有可能在一定时间内对同一接口发起相同参数的请求时,我们可能希望能够缓存接口数据,以便减少不必要的请求;这种缓存请求结果的需求通常根据粒度不同,实现的复杂程度也不太一样,不过肯定比上面提到的需求是要复杂的。
Alova
虽然上面提到的一些跟请求相关的需求都比较简单,几行代码就能搞定,不过一想到每个请求都要写一遍重复繁琐的代码,我就觉得不能忍。
Alova就是针对这些看似简单但其实挺繁琐的请求相关的业务处理进行提取,所形成的一个请求策略库,对于很多与请求相关的业务逻辑都提供了开箱即用的功能,简单的配置一下就能使用。对我个人来说,我挺喜欢他们官网上写的那句 slogan
——”一行代码完成各种复杂场景的网络请求,别再花时间在请求这件小事上了,交给我们“
关于 Alova
的具体使用,就不多说了,建议参考他们的官方文档,特别详细;我觉得只要想到了一些跟请求相关的需求,如果想偷懒的话去文档里面看看有没有相关的业务场景,说不定就有呢😁。
优点
API
为hooks
风格,跟目前主流前端框架风格匹配- 数据可以跟前端框架匹配,如框架选择
Vue
可以返回Ref
类型数据 - 进可攻,退可守:
Alova
的用法可以完全退化成传统请求库那种用法——即单纯的请求处理;因为后续的请求策略都是通过hooks
对接口实例进行包裹而得到的,所以不必担心使用了它之后就没法针对单个接口进行自定义的逻辑处理。
槽点
useRequest
执行时默认会执行一次发送请求[1]:这个设计个人觉得略微欠缺考虑,因为只有请求列表的一些接口才会需要立即执行,如果考虑到实际业务中通常需要对页面筛选数据加载完再进行列表的请求,那么这个立即执行的需求就更低了;且更要命的是默<font color=#f00>
认执行的请求并不会带请求参数</font>
,所以这个功能就更鸡肋了。因此在实际使用中,经常需要对useRequest
手动增加{immediate: false}
的配置,就挺繁琐的。useRequest
返回的请求函数<font color=#f00>
丢失了参数类型</font>
:我不知道为啥不按照传入的请求函数返回参数类型,而是直接使用any[]
,从技术上简单的使用TS
的类型推断就能做到,这种毫无必要的类型丢失会损害写TS
的开发体验。