这是一个创建于 218 天前的主题，其中的信息可能已经有所发展或是发生改变。
前段时间，我设计开发了一个叫做 alovajs 的 js 请求策略库，在 23 年 4 月份开始对外宣传以来已经取得了来自世界各地开发者的好评，也获得了 2400+stars ，其中不乏大厂的牛人的认可，这已经让我很兴奋得失眠了好几次。
本来只是一个普通的请求工具，但我希望它做一些其他请求工具没有做的，真正能帮助前端的事。经过不断地思考，推翻，再思考，再推翻，我想我确实找到了这个点，接下来把这个新想法分享给你。
在了解它前，还得简单说说 alovajs 的过去，这也可能会让对开源有更深入地认识，也希望可以给你提供一些能量。
如果对你有帮助，请帮忙点个赞或留下宝贵的评论，我都会一一认真阅读。
对啦，4 月 14 日（周天） 20:00 我将会开启一场直播，有空来聊聊啊，微信扫码提前预约↓↓↓
同时，如果你对 alovajs 感兴趣，也诚挚邀请你加入社区共同进步，我们也将会在微信群不定期直播分享一些技术干货。
alovajs 源于小项目，使命却是驶向大海
2022 年 3 月的一天，我因某种情况萌生了开发一个名叫“目标控”的 App ，那时候得益于微信设置功能和滴答清单的启发，我希望目标控可以实现无延迟的数据请求和提交，即立即响应模式，即使在弱网或断网模式下也可以正常使用，但由于在网上翻了一遍都没有合适的解决方案，相似的乐观更新方案也无法满足，该死的热爱分享欲又让我决定以一个请求库的形式实现它，这就是 alovajs 的萌芽点，但那会儿还没有这名儿呢。
设计 alovajs
一个库的开始不是设计，不是开发，而是理清需求
温馨提示：强烈建议你先简单了解下 alovajs 的概述部分，才能更好地理解下面的内容。
那会儿也没有产品定位可言，只是做出满足自己需求的 js 库，我研究了现有的请求库，列出了下面这些需求：
- 要支持无感数据交互模式，即在断网情况下也能正常提交且无延迟，让用户毫无感知
- 按时下热门的 useHook 设计，让接口更加易用
- 一套代码同时支持多种框架如 vue 、react 等，js 运行环境如浏览器、react-native 、uniapp 和 taro 等
- 多 js 环境下一致的使用方式
- 鉴于 react-query 的缓存功能很不错，这个也要加进来
- 由于 axios 的影响力和简便性，让 alovajs 容易上手，设计要类似 axios
然后根据需求进行库的 API 设计。
- 对于需求 1 是我做 alovajs 的出发点，但也不简单，当时的设计是在 useHook 的配置中加入了一个
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 和其他请求库有什么区别吗？用户为什么要用 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 作为和使用者的沟通桥梁。
alovajs 推广的心路历程
我自己对互联网推广真的是一窍不通，写文章又烂，毕竟搞技术的大多不擅长表达嘛，又没有办法沉下心来不断产出文章，但是不得不尝试一下。
我清楚地认识到，在推广这件事上需要做的，一点也不比开发少，而且需要有耐心，不能一蹴而就，也需要有自己的坚定信念，因为喷子真的无处不在。
所以在去年 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 的核心工作，这可能会让你获得丰厚的收益，有意愿进一步了解的朋友可以加我微信，具体可见成为核心成员。
24 条回复 • 2024-04-11 09:26:27 +08:00
 |
1
R1hu6Hs2sSN8pkVX 218 天前
一个好的库不需要推广
|
 |
2
TwilightCool 218 天前  13
感谢分享，已 Block
|
 |
3
tianzx 218 天前
写这么多，应该没人会看的
 |
 |
4
kneo 218 天前 via Android
写这么多都是流水账，自己总结，对别人意义不大。
|
 |
5
Light3 218 天前 2
鉴定为 推广
|
 |
6
uni 218 天前 1
楼上的怎么这么刻薄啊，正好这两天在搭前端框架，正好在纠结请求库的搭建，正好就看到这篇贴子，正好就挺能解决我们的需求，现在就决定用你这个试试
加油！ |
 |
7
yanyiming 218 天前
感觉是比较针对业务需求的库.
|
 |
8
lstz 218 天前 via Android 1
不要灰心，互联网就是这样，永远不缺冷嘲热讽的人
你所要做的就是坚持，有用的建议就听，没信息量的评论就当乐色就好 |
 |
9
katwalk 218 天前
楼主认为产品优势的清晰表述比复杂的营销手段更为重要，but 。。。
|
 |
10
PTLin 218 天前 3
难怪看这个库名这么熟悉，原来是这个 https://www.v2ex.com/t/948621#reply125
|
 |
11
43n5Z6GyW39943pj 218 天前 3
不会网络营销?我看你每次推广贴标题都很会起啊
|
 |
12
Eillott 218 天前 via Android
会营销怎么了，不会的程序员才在这阴阳怪气
|
 |
13
timedivision 218 天前
原来你就是作者，产品非常棒，也很佩服你的执行力，我在 github 上给你提了几个建议，还有加上了 onComplete ，哈哈哈
|
 |
14
panlatent 218 天前 via Android
才意识到我看 V2 更多的是想看评论
|
 |
15
qingyingwan 218 天前
第一眼看上去是营销推广。点到 github 看了下，代码是认真写的，issue 也是认真在讨论。虽然我目前还没有用的想法，但还是非常肯定这样的项目，希望越做越好
|
 |
16
qW7bo2FbzbC0 218 天前 1
@livid 推广
|
 |
17
darkengine 218 天前
为毛不直接放 github 链接啊。。。
|
 |
18
pytth 218 天前 via iPhone
内容太多了，没有看下去的欲望，一句话加个 github 会更有效果。
|
 |
19
ScottHU OP @whatFoxSay 6 ，我分享自己的经历也叫推广是吗？
|
|
23
ScottHU OP @timedivision 原来你就是贡献者，哈哈哈
|
|
24
ScottHU OP @qingyingwan 非常感谢你的认可，不过我分享自己的经历过程也叫推广啊？
|
Select Language