前段我发了一篇《是时候该换掉你的 axios 了》的文章引起了热议，各位小伙伴也给出了自己的看法，本来只是随便一发的对比 axios 和 alova 优劣势的文章，但是却遭到了一些同学的质疑。
思想碰撞是我们进步的阶梯，我没有要贬低这些质疑的意思，相反，我要感谢他们（质疑者）推着我思考和前进，在这边我想对这些声音做出自己回应。
因为我从这些质疑声中看到了，很多人的代码思维都还停留在使用层面，而缺少更深度的理解和思考，这篇文章我想聊聊我对开源框架和库更深入的观点，从更深入的角度聊聊我为什么看好 alova ！！！
看完我保证你一定会有所收获的，没有的话你尽管喷。 还不知道 alova 的可以预先了解下：
如果你不知道 axios 的话，直通车在这
本文主要讨论编程背后的东西，而不是某个技术点的解决方案，欢迎大家参与共同讨论！
省流目录
- react 和 vue 的伟大
- （解答各位的质疑） alova 的优势在究竟哪里
- （升华）开源框架罪恶史
react 和 vue 的伟大
深有体会的是，开源框架和库已经实实在在地给我们带来了太多便利，在深入讨论 alova 前，我们先从来 react 和 vue 等大家最熟悉的 UI 框架说起。
这些 UI 框架究竟给我们带来了什么，过去的王者 jquery 可谓雄霸天下，jquery 所解决的问题是提供一种更简单兼容性更好的 dom 操作 api ，让大家不需要关注兼容性问题，但对于新手来说，照样会把全部代码写在一个 js 文件中然后把代码乱放，来欣赏一段意大利泡面一样的 jquery 代码：
// 整个页面的 js 处理都集中在这里了 (function(win) { // 处理页头按钮点击事件 $('#header .button').click(function() { // ... }); // 处理页脚某个 tag 的鼠标移入事件 $('#footer .tag').mouseenter(function() { // ... }); // 处理主界面轮播图的事件 $('#swiper .btn-left').mouseenter(function() { // ... }); $('#swiper .btn-right').mouseenter(function() { // ... }); })(window); 项目以 html 、js 、css 为大模块进去分开，结构大概是这样的
一团扭来扭去还弯弯曲曲的代码，可维护性直降负分，谁愿意接盘谁倒霉，随着项目逐渐复杂，每改动一处都像是一锤子锤在接盘侠的胸口上 痛苦无比，只要团队里有新手，不管技术 leader 怎么制定模块拆分的规范都无法避免这种事的发生，最终接盘侠们也抛了盘……
为什么呢？
因为 leader 的规范只是写在文档上的意见型规范，你可以不遵守也能让项目跑起来。而 react 和 vue 等 MVVM UI 框架（以下简称 UI 框架）的优势就立即凸显出来了，这让它们很快把过去的王者 jquery 击败了，这些 UI 框架的最伟大之处就在于，它们提供了一种可维护性更高的代码组织模式 组件化，并强制大家都使用这种方式来开发应用。组件化中，html 、js 、css 以组件为最小单元聚合，组件之间相互解耦，大概是这样的
它们形成了一种制约型规范，不遵守项目就无法跑起来，这种方式让天底下的前端开发者达成了统一的模块化共识，就像你家的电源插槽那样统一。
我觉得以上就是框架和库的区别！！！
这种制约型规范才能让组件库百花齐放，各种组件库开始诞生进一步为大家减少开发量。
这就是制约型规范的威力，可能你突然就懂了为什么要用 husky 了。
而使用数据驱动视图的 MVVM 模式，虽然相比于 jq 也是降维打击的存在，但我觉得它的重要性并没有组件化伟大。
（重要）制定规范的目的除了规范变量名和注释外，更重要的是在代码组织层面实现高聚合、低耦合， 不陌生吧，而且我觉得 vue 的 SCF 、指令相比 react 的 jsx 又进一步做到了强制型规范。
（解答各位的质疑） alova 的优势在究竟哪里
如果你理解了上面的规范问题，我们再接着聊相比于react-query、swr、vueuse 的 useFetch以及ahook 的 useRequest等，alova 有什么特别之处？我很认同作者在《是时候该换掉你的 axios 了》中的评论：
在得知我还要再发一篇深度解析文后，在周一晚上，作者找到了我，聊了 3 个小时，他表达了不希望 alova 被我带偏了，那次聊过后也体会到了作者的思想，大概如下：
js 库可以分为规范型 js 库和功能型 js 库
规范型 js 库
像 react 和 vue 等 UI 框架除了提供 api 外，还提供了组件化（制约型规范），很显然是规范型的库，即框架。
功能型 js 库
如 axios 、moment 、lodash 、jquery 等都是属于功能型 js 库，它们更多的价值是提供便于调用的 api ，而 react-query 和 swr 等确实是使用 use hook 管理请求以及使用请求缓存的先驱者，但好像除了这些再没有规范层面的影子，因此更倾向于把它们归类到功能型 js 库中，贴上示例。
react-query 官方示例简析
function Example() { // 在每次 useQuery 中调用 fetch 或 axios 发送请求，耦合度较高 // 需手动维护 queryKey const { isLoading, error, data } = useQuery({ queryKey: ['repoData'], queryFn: () => fetch('https://api.github.com/repos/tannerlinsley/react-query').then( (res) => res.json(), ), }) if (isLoading) return 'Loading...' if (error) return 'An error has occurred: ' + error.message return ( <div> <h1>{data.name}</h1> <p>{data.description}</p> <strong> {data.subscribers_count}</strong>{' '} <strong> {data.stargazers_count}</strong>{' '} <strong> {data.forks_count}</strong> </div> ) } swr 官方示例简析
// 耦合的方式请求 const fetcher = url => fetch(url).then(r => r.json()) function App () { const { data, error } = useSWR('/api/data', fetcher) // ... } // 解耦的方式 import useSWR, { SWRConfig } from 'swr' function Dashboard () { const { data: events } = useSWR('/api/events') const { data: projects } = useSWR('/api/projects') const { data: user } = useSWR('/api/user', { refreshInterval: 0 }) // override // ... } function App () { return ( <SWRConfig value={{ refreshInterval: 3000, fetcher: (resource, init) => fetch(resource, init).then(res => res.json()) }} > <Dashboard /> </SWRConfig> ) } 我觉得 vercel 团队是有思考到这点的，只是把解耦的方式作为了一个可选项。
alova 的不同之处
虽然 alova 相比于 axios 、react query 、swr 等前辈大咖，alova 只能算是新秀中的新秀，其他库已经发展了 5 到 10 年了，作者好像也比较低调。但在我看来 alova 在解决思想上和前辈们相比会更加深入，也更加彻底。
alova 的作者提出了一个叫 RSM 规范（请求场景模型） 的模型，并让 alova 遵循这个模型来设计，官方示例代码如下：
import { createAlova } from 'alova'; import GlobalFetch from 'alova/GlobalFetch'; import VueHook from 'alova/vue'; const alovaInstance = createAlova({ // 假设我们需要与这个域名的服务器交互 baseURL: 'https://api.alovajs.org', // VueHook 可以帮我们用 vue 的 ref 函数创建请求相关的，可以被 Alova 管理的状态 statesHook: VueHook, // 请求适配器，我们推荐并提供了 fetch 请求适配器 requestAdapter: GlobalFetch(), // 全局请求前钩子 beforeRequest(method) { // ... }, // 全局响应钩子 responsed: { onSuccess(response, method) { // ... }, onError(err) { // ... } } }); // 创建一个 Get 实例，描述一次 Get 请求的信息 const todoListGetter = alovaInstance.Get('/todo/list', { // 请求头 headers: { 'Content-Type': 'application/json;charset=' }, // params 参数将会以?的形式拼接在 url 后面 params: { userId: 1 }, // 单独为这个请求设置缓存时间 localCache: 50000, // 单独为这个请求开启请求共享 shareRequest: true, // 数据转换 transformData(result) { // ... }, // ... }); 从以上示例中，可以看出 alova 的以下两个优势：
- alova 以请求适配器、存储适配器、UI 框架适配器的方式，将请求工具和请求方式进行了强制解耦，实现了低耦合，提高了代码的可移植性，而不是可选项。
- alova 中的 Method 概念，用于实现 RSM 的请求行为，它也强制将请求相关的信息、请求行为相关的信息高度聚合在了 Method 中，实现了高聚合。
作者原话告诉我：alova 提供了高聚合低耦合的代码组织方式，可以更大程度地管理请求相关的代码，随着项目越来越复杂，它的优势也就会慢慢显现出来，而且在编码方面也更加统一了。同时保持了高度了灵活性，供用户提供了足够的自定义空间。
因此，我会把 alova 放在介于规范型库和功能型库的中间位置
最后，据官网介绍，alova 的目标是通过按业务场景来实现兼开发体验和用户体验为一体，而 alova 的高度灵活性就可以支持自定义策略，你可以封装了公司内部用，比如你的公司很喜欢用某种处理来优化性能，或者写成 alova 插件一样的自己的策略库，那 alova 刚好都可以提供支持。
说到这边，好像 alova 的 use hook 形式显得好像没那么重要了，这个就要问作者了。不懂有没有解答大家的疑问。
（升华）开源框架罪恶史
react 和 vue 都更关注 UI 层面，它们简化了 UI 层面的问题，但据我的理解，目前从 js 逻辑的层面却还是没有统一制约规范，或相关的 js 逻辑框架来解决这个问题，新手和高手写出的代码可维护性上还是有一定差距的。UI 框架让事情简单化的同时，也养肥了一堆躺在 UI 框架的成绩上好吃懒做的人，这些人往往会有以下两个问题：
- 不再思考规范问题、模块之间的界限和协作，甚至都意识不到这些东西的存在，然后不分职责、把代码到处乱写，请想象有一只狗到处乱拉……，然后堆积成的叫什么山。
- 他们只享受上层成果，不再关注底层的东西，哪怕稍微底层一点的，因为确实用不着了，就像我们不再关注垃圾回收的问题（ C 语言里是需要手动回收的），更离谱的是，有些人连
getElementById、appendChild、insertBefore是干什么的，更别问他们 noetype 有几种类型，fragment 是什么，注释是不是一种 node 等等。
可想而知，尖端人才变少是有理由的，知道为什么高级前端难招了吧！！！当然也不乏一小部分喜欢钻研的同学，喜欢知其然知其所以然。
这好像是时代发展、科技进步带来的无法避免的副作用，它们为我们提供了强大且便利的工具外，也在慢慢摧残着这么一大群人，和平年代不需要那么多英雄。这让我又想到了《反脆弱》里的观点 现代化是这个世界的脆弱推手。
插个题外话，毕竟 react 和 vue 接管的是 UI 层面的组件化规范，但在 js 逻辑层面的规范都还停留在文档上，还没有形成制约型规范，在这个层面新手朋友一样可以把它们写成意大利面，有兴趣的同学也可以开始思考一下了，有没有可能从 js 逻辑层面提出制约型规范，然后形成一个新的 js 框架，就像 UI 框架组件化规范一样，如果有人做到了，可否回来留言告诉我下
结尾
这篇文章并没有去解决一个具体问题，能看到这里的同学，看来都是学习和交流的同学。
那问题来了，你们理解的代码规范是怎样的呢？
1
Select Language