两年前，我设计并开发了一个名为alovajs 的 JavaScript 请求策略库。自2023年4月推广以来，获得了全球开发者的一致好评，并获得了超过2700+颗星，其中包括各大公司专家的认可。
目前alova@3.x已经发布，定位为“简化工作流程的下一代请求工具”
我无偿维护了30个月，版本已经到了3.x。这段时间，通过不断的反思、拒绝、重新思考，我的目标是做到一些其他请求工具没有做到的事情，成为一个真正能够帮助前端开发的工具。我相信我已经找到了可靠的方向。
即打造“下一代精简流程的请求工具”，最大限度地协助前端开发精简API集成流程。
下面是alovajs的探索故事，也是一个开源项目从诞生开始的故事。
如果你对alovajs感兴趣，真诚邀请你加入社区，共同进步。
alovajs 起源于一个小项目，但它的使命是扬帆海洋
2022年3月的一天，由于某些情况，我萌生了开发一款名为“Con of goal”的应用程序的想法。受到一些应用的启发，我希望“Con of goal”能够实现无延迟的数据请求和提交，即即时响应模式，即使在弱网络或无网络的情况下。然而在网上搜索并没有找到合适的解决方案，而且类似的乐观更新方案又不能满足需求，我该死的分享欲望让我决定以请求库的形式来实现，这就是alovajs的出发点，但当时还没有名字。
设计阿洛瓦杰斯
库的开始不是设计，不是开发，而是明确需求
专业提示：强烈建议您先简单了解一下alovajs的概述部分，以便更好地理解下面的内容。
当时没有产品定位，只是创建一个JavaScript库来满足自己的需求。我研究了现有的请求库并列出了以下需求：
- 支持无缝数据交互模式，即在断网情况下，仍然可以无延迟提交，用户无感知
- 根据当时流行的useHook设计，使界面更加人性化
- 一套代码支持Vue、React等多种框架，以及浏览器、React Native、UniApp、Taro等JavaScript运行环境
- 多种 JavaScript 环境中的一致使用
- 考虑到react-query的缓存功能很好，这个也应该加上
- 由于axios的影响和简单性，让alovajs容易上手，设计应该和axios类似
然后根据需求，设计了库的API。
- 对于需求1，是我做alovajs的起点，但并不简单。当时的设计是在useHook配置中添加一个silent参数，可以立即响应成功回调，但后来证明是有问题的，重新设计，这就是现在的无缝数据交互策略
针对需求2，设计了三个核心useHook：useRequest、useWatcher、useFetcher。这个大家都很熟悉了，比如ahooks的useRequest、vueuse的useAsyncState、react-query、swr，不用说，确实很方便。
由于采用了useHook设计，不同的框架会有不同的状态管理，但我不想像react-query那样为每个框架创建一个JavaScript库。因此，针对需求3，设计了stateHook适配器、请求适配器、存储适配器的规范，可以根据规范编写不同的适配器，将框架环境和运行时环境相关逻辑分离到单独的模块中。
针对需求4，设计了方法实例代理模式，方法实例代理调用不同适配器的钩子函数，这样即使你开发任何应用，都可以上手alovajs，没有任何陌生感，而且还可以无缝移植。
对于需求5，类似的JavaScript库以自定义键的形式实现缓存，但我的想法是专注于请求信息。常见的场景是，用相同的请求方法和参数请求同一个接口时，需要命中上次的响应数据。为什么我们不使用这些请求信息作为缓存键呢？因此，alovajs 设计了一种自动缓存机制，在 GET 请求上默认启用该机制。
需求6，参考axios学习。
这些设计确实已经被时间证明了。 alovajs 通过适配器的方式完美兼容了 Vue、React、Svelte 框架，并且还可以运行在浏览器、React Native、UniApp、Taro 等各种 JavaScript 环境中，同时保持了一致的使用方法，这让我看到了一丝希望。
接下来的几个月，alovajs虽然发布了，但一直没有推广。一方面是因为我在“Con of goal”项目中使用了它。虽然在这个项目中得到了锤炼和完善，但还是很不完整，定位不明确。初始版本介绍是这样的
后来“Con of goal”项目流产了，但alovajs还在坚持。
alovajs的方向探索
怀着曾经做互联网产品经理的执念，我还是希望把alovajs打造成一个差异化的产品。我经常问自己，alovajs 和其他请求库有什么区别？用户为什么要使用alovajs？它在设计上确实与其他库不同，这不是一个可以立即回答的问题。后来我尝试将请求库的方向定位为“轻量级请求库”和“多端统一请求库”，但都被自己否定了，因为这些不能给开发者带来实质性的帮助，也不能才叫优势。
2022年9月，一个机会让我发现了基于Vue的优秀请求库，vue-request。它的 usePagination 和 useLoadMore 立即启发了我。这种形式的分页实现让我意识到这也是我想要的。同时也让我认识到了useHook的强大。我可以根据请求场景来划分模块，针对不同的场景使用不同的useHooks，而之前实现的无缝数据交互其实也是场景之一。如果是这个方向的话，开发者可以根据不同的请求场景选择不同的useHooks，这样不仅提高了开发效率，降低了编码复杂度，也避免了初级前端写出低效的代码，并且可以更好的利用核心功能alovajs 以实现更好的性能和更少的服务器压力。请求特性，至此，“轻量级请求策略库”是我选择的。
然后，为了指导alovajs未来的设计方向，我还对alovajs的请求场景模型（RSM）进行了提炼和抽象，主要分为以下四个流程：
Request timing -> Request behavior -> Request event -> Response processing
登录后复制
开始吧，我按照这个定位开始重构alovajs 2.0，将无缝数据交互功能从1.0中分离出来，设计了中间件机制来适应更多请求场景策略的开发useHooks，研究开发了分页策略和无缝数据交互策略。
alovajs的分页策略是我认为最有用的usePagination。利用alovajs的缓存功能实现前后页数据预加载、分页数据搜索、请求级去抖，并提供新增编辑删除功能的自动化管理，以及刷新指定页面代码的数据无需重置。
无缝数据交互策略花了我4个月的时间，不断遇到死胡同，不断重新设计结果。它实现了即使在弱网或断网环境下也可以让用户无延迟地与数据交互的策略，同时也能更稳定地保证请求的成功。我设计了一个虚拟数据的东西，可以在响应前作为响应数据的占位符，让用户感觉是立即响应，然后在响应成功后用真实数据替换虚拟数据。根据目前的探索结果，它的使用场景可以是类似编辑器的应用、系统设置模块以及一些更简单的列表。
后来还添加了useForm、useAutoRequest、useSSE等请求策略模块，但这还远远不够。
下一代请求工具的想法
2023年5月13日，我在github上收到这样的issue
一开始我并没有太关注这个问题，只是简单了解了openAPI自动生成请求码的功能，觉得非常好，但是由于精力有限，并没有深入思考那个时候我还没有考虑alovajs的方向。但最近，我偶尔会思考alovajs的方向，这个仍然悬而未决的问题一直浮现在我的脑海中，然后悄悄地将这个问题的标签从“feature-request”更改为“feature-request:confirmed” .
同时这个问题让我认识到alovajs还可以拉近前端和后端的协作距离，进一步简化前端开发工作流程。这是我为alovajs 3.0设定的开发方向：
alovajs将最大程度地帮助开发者简化API集成工作流程，你只需要指定使用哪个API即可（这也是思考了3个月的结果）
我的具体计划如下：
上图中的步骤1、2、3、4、6是通过自动生成API代码来解决的，但是我们的生成计划相比openapi-generator这样的工具会更进一步。会自动生成完整的ts类型，完整的描述请求函数，无论是js项目还是ts项目，都无需引入，让开发者调用就像直接调用location.reload一样方便，并且请求函数可以直接看到完整的描述和请求参数类型提示。
由于自动生成的请求函数有完整的描述和类型提示，vscode插件完成了交互方式快速检索所需API，不再需要查阅API文档。
解决前后端协作鸿沟问题，界面任何变化都可以自动通知前端。如果项目构建过程中发现有变化，就会抛出错误并停止构建。如果是ts项目，编译时也会抛出错误，也可以通过vscode插件查看变更记录
这里是 vscode 扩展的演示视频。
如何解决第6步“编写复杂的请求逻辑”？当然是利用请求策略模块，它具有高性能、场景化的特点，用户可以用极少量的代码实现各种场景请求功能。
2024年3月，制定了alova@3.0的开发计划，花了4个月的时间与核心成员MeetinaXD重组了几乎整个项目，并且有很多优化：
底层架构进行了重新设计，一组钩子可以在 Vue、React、Svelte 甚至 Vue options 风格中同时使用。
可用范围已增加到服务器端。您可以在express、koa、nestjs等服务器端框架中使用alova，并且添加了新的服务器端请求策略服务器钩子。
alova@2.x 中的 10 个配置已弃用，并优化了 9 个设计。
另外，3.0最重要的部分，我们核心成员czlin负责的vscode插件也可用了，基本达到了我们一开始设定的目标。
至此，alova@3.0已经过了内测期，可以在生产环境中稳定使用了。
只有不断探索，才能变得更好
当时一篇被诟病的文章《是时候更换你的axios了》上了热搜。
刚推出的时候确实没有那么好，但我知道每一个产品都不是一蹴而就的，需要时间的沉淀。
Apple 1电脑一开始连外壳都没有
Vue的发展历程也是一个不断探索、不断进步的过程
我就是被这样的产品之旅所感动，坚持做一件事是最容易成功的方法。好的产品都需要经过好几年的考验，更何况alovajs，它才出现了1.5年左右，也才被一些人接触了8个月。这期间，也一直在探索更好的解决方案，一步步向前。
alovajs 最初设计的 useHooks 包括 useRequest、useWatcher、useEffectWatcher、useManual、useController，后来逐渐减少到只有三个核心 hook：useRequest、useWatcher、useFetcher。
提交地址
并行请求的设计中，是实现类似Promise.all的形式，还是现在绑定onSuccess函数的形式，我纠结了好几个版本，来回改了，下面是当年被遗弃的响应者的设计。
未找到提交记录
为了兼容IndexedDB等异步缓存方案，我最初尝试将存储适配器设计为异步功能，但会带来一系列问题，然后尝试通过StorageConnector实现事件机制，这还是不够完善，最后到了目前自定义的localCache异步函数机制。
提交地址
也感谢支持alovajs并做出贡献的朋友们。以下是几张截图，还有很多贡献没有收录。
并不断补充文档细节和完善最佳实践，大胆尝试缓存恢复模式的缓存版本计划，并为了给alovajs提供完整的ts类型提示，尝试使用自动类型推断来减少开发者定义类型的麻烦，确实要花很多精力去优化、兼容不同的UI框架等等
其中文档已经大改了两到三次。感谢@Orange Peel提供了第一次文档修改意见，感谢@Well提供了第二次文档修改意见，我们的文档才有了这样的声誉。
@green tree 帮助我为 alova 开辟了新的想法。
很多事情已经不太清楚了，npmjs 上的记录告诉我已经发布了 146 个版本。
github上也有很多人提出了Bug，我也第一时间回复并修复了。我真的非常非常感激。如果我不能立即判断问题，我也会在codesandbox上重现，并用这个demo作为与用户沟通的桥梁。
结束
非常感谢您的阅读？，再困难，路还是要继续。
如果您认识alovajs，请前往Github给它一个star。
如果你想了解alova，可以访问官方网站，在这里你可以找到更详细的文档和示例代码，帮助你更好地理解和使用这个工具。
如果您有任何疑问，可以加入以下群聊进行咨询，也可以在github仓库中发表讨论。如果您遇到问题，请在github issues中提交，我们会在最快的时间内解决。
也欢迎您贡献自己的力量，请前往贡献指南。
以上是开源月数：我如何维护下一代请求工具的详细内容。更多信息请关注PHP中文网其他相关文章！
