前段时间，我设计开发了一个叫做 alovajs 的 js 请求策略库，在 23 年 4 月份开始对外宣传以来已经取得了来自世界各地开发者的好评，也获得了 2400+stars ，其中不乏大厂的牛人的认可，这已经让我很兴奋得失眠了好几次。
本来只是一个普通的请求工具，但我希望它做一些其他请求工具没有做的，真正能帮助前端的事。经过不断地思考，推翻，再思考，再推翻，我想我确实找到了这个点，接下来把这个新想法分享给你。
在了解它前，还得简单说说 alovajs 的过去，这也可能会让对开源有更深入地认识，也希望可以给你提供一些能量。
如果对你有帮助，请帮忙点个赞或留下宝贵的评论，我都会一一认真阅读。
对啦，4 月 14 日（周天） 20:00 我将会开启一场直播，有空来聊聊啊，微信扫码提前预约↓↓↓
同时，如果你对 alovajs 感兴趣，也诚挚邀请你加入社区共同进步，我们也将会在微信群不定期直播分享一些技术干货。
2022 年 3 月的一天，我因某种情况萌生了开发一个名叫“目标控”的 App ，那时候得益于微信设置功能和滴答清单的启发，我希望目标控可以实现无延迟的数据请求和提交，即立即响应模式，即使在弱网或断网模式下也可以正常使用，但由于在网上翻了一遍都没有合适的解决方案，相似的乐观更新方案也无法满足，该死的热爱分享欲又让我决定以一个请求库的形式实现它，这就是 alovajs 的萌芽点，但那会儿还没有这名儿呢。
一个库的开始不是设计，不是开发，而是理清需求
温馨提示：强烈建议你先简单了解下 alovajs 的概述部分，才能更好地理解下面的内容。
那会儿也没有产品定位可言，只是做出满足自己需求的 js 库，我研究了现有的请求库，列出了下面这些需求：
然后根据需求进行库的 API 设计。
silent参数，它可以立即响应 success 回调，但后来也证明有问题，并且重新设计了，也就是现在的无感数据交互策略针对需求 2 设计了 useRequest 、useWatcher 和 useFetcher 三个核心 useHook ，这个大家都很熟悉了，例如 ahooks 的 useRequest 、vueuse 的 useAsyncState 、react-query 以及 swr 这些，自不用多说，确实很方便
既然要用 useHook 设计，那么不同框架需要会有不同的状态管理，但又不想像 react-query 一样针对每一个框架搞一个 js 库，因此针对需求 3 设计了 statesHook 适配器、请求适配器、存储适配器的规范，并按规范编写不同适配器即可，将框架环境和运行环境相关逻辑剥离成单独的模块。
针对需求 4 设计了 method 实例代理的模式，method 实例代理去调用不同适配器的钩子函数，这样即使你开发任何应用都可以毫不陌生地上手 alovajs ，也可以无缝移植
对于需求 5 ，同类 js 库都是自定义 key 的形式实现缓存的，而我的思路却放在了请求信息上，常见场景是在以相同请求方式、相同参数请求相同接口时需要命中上一次的响应数据，那我们何不把这些请求信息作为缓存 key 呢，因此 alovajs 设计了自动化的缓存机制，在 GET 请求上默认是开启的。
需求 6 嘛，借鉴参考一下 axios 。
这些设计确实在以后的时间里得到了证实，alovajs 已经通过适配器的方式完美兼容了 vue 、react 、svelte 框架，并且也可以在浏览器、react-native 、uniapp 和 taro 等多种 js 环境下运行，并且保持了一致的使用方式，这让我看到了曙光。
在这之后的几个月里 alovajs 虽然发布了，但一直没有去宣传它，一方面是因为我就是拿他用在“目标控”项目上的，虽然它在这个项目上历练完善了一番，但依旧很不完整，定位也不清晰，最初的版本介绍就是这样的。
到后来，“目标控”项目已宣告夭折了（但官网还在），但 alovajs 却还在继续坚持着。
本着曾经互联网产品经理身份的执念，我还是希望将 alovajs 打造成一个差异化的产品。我常常会问自己，alovajs 和其他请求库有什么区别吗？用户为什么要用 alovajs ？它在设计上确实和其他库有些不一样，这并不是马上能回答出来的问题。后来我尝试将请求库的方向定位在“轻量级请求库”、“多端统一的请求库”，但后来都被自己否定了，因为这些都不能为开发者带来实质性的帮助，也都不能称之为优势。
时间来到了 22 年 9 月份，一次契机让我发现了 vue-request 这个优秀的基于 vue 的请求库，它的usePagination和useLoadMore立刻给了我灵感，这种分页的实现形式让我发现这也是我想要的，同时这让我意识到 useHook 的力量之强大，我可以把它按请求场景切分模块，根据不同场景使用不同的 useHook ，而且之前实现的无感数据交互其实也算是其中一种场景。如果以这为方向的话，开发者按不同的请求场景选择不同的 useHook 就可以了，既提高了开发效率、降低了编码复杂度，又能防止初级前端写出低效代码，还能更大化地利用 alovajs 的核心特性实现性能更好、服务端压力更小的请求功能，至此，“轻量级的请求策略库”被我选中了。
然后为了指导 alovajs 以后的设计方向，我还提炼抽象出了 alovajs 的请求场景模型（ RSM ），主要分为以下四个流程：
请求时机 -> 请求行为 -> 请求事件 -> 响应处理
这里就简单提一下。
说干就干，我根据这个定位开始重构 alovajs2.0 ，将无感数据交互功能从 1.0 中剥离出来，并设计了中间件机制来适应更多请求场景策略 useHook 的开发，潜心研究并设计开发了分页策略和无感数据交互策略。
alovajs 的分页策略是我自认为最好用的usePagination，它利用 alovajs 的缓存功能实现了前后页数据的预加载、分页数据搜索和请求级防抖、提供自动化管理的新增编辑和删除函数，以及无需重置地刷新指定页码的数据。
无感数据交互策略更是花了我 4 个月时间，不断遇到死胡同，又不断重新设计的成果，实现了一个即使在弱网或断网环境下，用户也能无延迟的数据交互策略，同时它也可以更稳定地保证请求成功。我设计了一个虚拟数据的玩意儿，可以让请求在响应之前作为响应数据的占位符使用，让用户感觉是立即响应的，当响应成功后 再将虚拟数据替换成真实数据。按目前的探索结果，它的使用场景可以是编辑器类的应用、系统设置类模块，以及部分较简单的列表中。
在后来也陆续增加了其他的请求策略模块，但这还远远不够。
到现在，alovajs 收到了一些负面评论，但更多的好评让我对这个项目有了更多的动力，谁还在乎那些负面评价呢。
23 年的 5 月 13 日，我在 github 上收到了这样一个 issue
起初我并没在意这个 issue ，只是简单了解了下 openAPI 自动生成请求代码的功能，觉得很不错，但迫于经历有限也没深入思考，那会儿也还没在思考 alovajs 的方向。但在最近，我又会偶尔思考 alovajs 的方向，这个还是 open 状态的 issue 一直跑到我的思绪里，然后默默地把这个 issue 的 label 从"feature-request"改成了"feature-request:confirmed"。
同时，这个 issue 让我灵光闪到，其实 alovajs 还可以拉近前端和后端的协作距离，并更进一步地简化前端开发的工作流，这就是我为 alovajs 制定的下一个发展方向：
alovajs 将在请求方面帮你省去大部分的工作，你只需要指定使用哪个 API ，以什么策略执行请求就可以了。别再花时间在请求这件小事上了，交给 alova
具体如下：
自动生成 ts 类型完整的、描述完整的请求函数，无论是 js 项目还是 ts 项目，都调用无需引入，让开发者就像直接调用location.reload这样方便，并且请求函数可直接看到完整的描述和请求参数类型提示，这些都可以由 openAPI 自动生成。
由于自动生成的请求函数拥有完整的描述和类型提示，通过 vscode 插件完成交互式的方式快速检索需要使用的 API ，你也不再需要去查阅 API 文档了。
解决前后端协作断层的问题，接口的任何变动前端可自动被通知，如果在构建项目时发现存在变动，则会抛出错误停止构建，如果是 ts 项目也会在编译时抛出错误，也可以通过 vscode 插件查看变动记录。
先发一张剧照，直接在编辑器中根据接口描述或接口地址来插入接口调用函数。
具体的方案可点此查看 alova 产品白皮书及 3.0 更新一览。
如果这个能实现，应该能为前端技术实打实地做出一点贡献吧。
同时，alovajs 将会探索更广泛的使用场景，例如适配兼容 solidjs 、preact 、angular 、lit 、原生小程序等更多框架和 js 环境，最终，我们会实现这样一个蓝图
当时一篇被吐槽的文章《是时候该替换你的 axios 了》冲上了热搜，我们曾经收到过这样的评论
在刚推出来的时候确实没那么好，但我深知每个产品都不是一蹴而就的，它需要时间沉淀。
Apple 1 电脑开始连机箱都没有
vue 的发展旅程也是不断摸索前进的过程
我只是被这样的产品历程所打动，坚持做一件事是最容易成功的途径，好的产品都要经过几年十几的考验，何况 alovajs 也只有 1 年半左右时间，被一部分人接触只有 8 个月。在这个期间也在一次次地探索更好的方案一步步前进的。
alovajs 开始设计的 useHook 包含 useRequest 、useWatcher 、useEffectWatcher 、useManual 、useController ，然后再慢慢缩减为只有 useRequest 、useWatcher 、useFetcher 三个核心 hooks 。
在并行请求的设计上，是自定义实现一个类似 Promise.all 的形式，还是现在的 onSuccess 函数绑定形式，在这里纠结了好几个版本，改来又改去，以下是当年被废弃的 responser 设计。
Commit 记录找不到了
为了兼容 IndexedDB 等异步的缓存方案，一开始尝试将存储适配器设计为异步函数，但会带来一系列问题，然后又尝试 StorageConnector 通过事件机制实现，依然不够完美，最后再到现在的自定义 localCache 异步函数机制。
也感谢对 alovajs 做出支持和贡献的朋友们，以下随便截了几张图，还有很多未被包含的贡献。
以及对文档不断地对细节补充和最佳实践的完善、对缓存恢复模式大胆尝试了缓存版本的方案，以及为了让 alovajs 可以提供完整的 ts 类型提示，尽量地使用自动推断类型来减少开发者定义类型的麻烦，在这方面也确实花了很大的精力优化和兼容不同的 UI 框架等等。
其中，文档大改了两到三次，感谢 @橘子皮 给我提供了第一次文档修改的意见，@well 给我提供了第二次文档修改的意见，然后我们的文档就有了这样的口碑。
@青木 却帮我打开了新的 alova 全端思路。
得供起来！
很多已经记不清楚了，npmjs 上的记录告诉我已经发布了 146 个版本。
github 上也有很多人提出 bug ，我也在第一时间回复和修复，真的非常感谢，如果无法马上判断问题所在，我也会在 codesandbox 上自行复现，并用这个 demo 作为和使用者的沟通桥梁。
我自己对互联网推广真的是一窍不通，写文章又烂，毕竟搞技术的大多不擅长表达嘛，又没有办法沉下心来不断产出文章，但是不得不尝试一下。
我清楚地认识到，在推广这件事上需要做的，一点也不比开发少，而且需要有耐心，不能一蹴而就，也需要有自己的坚定信念，因为喷子真的无处不在。
所以在去年 8 月份尝试编写了一篇文章，然后在网上发一些介绍的文章，在 QQ 群里发广告消息，但发现没什么效果，QQ 群里还遭人讨厌，但也收获了 alovajs 的第一颗 star ，应该也是出于同情心给的吧，效果甚微。
直到确定好了定位，项目 2.0 重构完成后，才开始编写大量 demo ，让人在了解后可以马上尝试一下。
在 23 年 4 月初，碰运气写了一篇爆款文章获得了不错的阅读量，沾了 axios 的光，然后网上开始陆续有人试用并分享出了自己试用的情况，也有人开始推荐 alova 了，这让我很欣慰。
但很多人对 alova 都是持怀疑态度，又是一个重复的轮子，在没有名气的时候被这样认为也无可厚非，当然，现在也只是稍微有名就了一点点，还需更加努力。
在需要帮别人复现 bug 、改 bug 、思考新特性设计、维护文档的同时，还需要思考如何推，执行推广工作真的是一件很累人的事。
但不能不推吧，然后就想把教程搬过来发一遍，总比没有好，不过这真的没啥人看。
也还发过一些类似自擂自吹的，没有说明白的文章。
但这种确实会让人反感想想自己看到这样的文章也是这样的反应。
所以在这方面确实有点力不从心，alovajs 也就只在发了这些文章的情况下成长的。
之前听一位营销大佬说过一句话：
做营销应该是做一组军体拳，而不是花里胡哨的舞技
这句话让我对产品推广有了思维上的转变，产品好的话，只要把它的优势说清楚就行了，而不用搞过多的花拳绣腿，然后把产品体验和学习门槛降到足够低，比如一件体验产品，以及出个视频教程之类的。
现在我就在这诚心地邀请正在看文章的你来体验体验 alovajs：
alovajs 是一个请求策略库，它提供了一套完整的应对复杂请求场景的方案，我们称之为请求策略，只需一行代码就能快速实现各种复杂的请求逻辑，不仅能帮你提升开发效率，还能帮你提升 App 的运行效率，降低服务端压力。
感兴趣的话可以前往alovajs 概述了解详情，这里也有一些 alovajs 示例，你可以立即体验体验，喜欢就直接拿去用，我也不赚你一分钱。
如果喜欢的话，还请帮忙发发朋友圈、掘金文章，或者抖音 b 站发视频都行，你的分享可以让更多人从 alovajs 中受益，也可以加入我们的社区，我们也将会在微信群不定期直播分享一些技术干货。
别忘了，4 月 14 日（周天） 20:00 我将会开启一场直播，有空来聊聊啊，微信扫码提前预约↓↓↓
能看到这边的你，应该花了不少耐心吧，非常感谢你的阅读🤗！
alovajs 至今已得到一定的可行性验证，为了加快发展，现需邀请两名认同 alovajs 的朋友加入核心团队（现已确认一名），负责 alovajs 的核心工作，这可能会让你获得丰厚的收益，有意愿进一步了解的朋友可以加我微信，具体可见成为核心成员。
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.