这次，我们想真正为前端开发的你做点儿贡献
前段时间，我设计开发了一个叫做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示例，你可以立即体验体验，喜欢就直接拿去用，我也不赚你一分钱。
别忘了，4月14日（周天）20:00我将会开启一场直播，有空来聊聊啊，微信扫码提前预约↓↓↓
寻找志同道合的人
能看到这边的你，应该花了不少耐心吧，非常感谢你的阅读🤗！
alovajs至今已得到一定的可行性验证，为了加快发展，现需邀请两名认同alovajs的朋友加入核心团队（现已确认一名），负责alovajs的核心工作，这可能会让你获得丰厚的收益，有意愿进一步了解的朋友可以加我微信，具体可见成为核心成员。