V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
az22c
V2EX  ›  前端开发

为什么基于浏览器 fetch 的封装的请求库这么少?

  •  
  •   az22c · 2020 年 12 月 31 日 · 4189 次点击
    这是一个创建于 1845 天前的主题,其中的信息可能已经有所发展或是发生改变。
    看公众号的文章,动不动就“传统 ajax 已死,fetch 永生”。

    但是看到现在基于 xhr 的封装的,成功的请求库还是很多,axios 、swr 、还有各种 react hooks 。

    反观对 fetch 的封装,封装场景比如有带上 cookie 、timeout 、调用.json()等等,也是可以封装的。但是很多的这方面封装,都是完成度比较低的,都是些简单的 demo 。很少看到有做得完善的并且有点人气的封装 fetch 的请求库。
    11 条回复    2021-04-18 10:50:23 +08:00
    KouShuiYu
        1
    KouShuiYu  
       2020 年 12 月 31 日
    兼容性,技术惯性
    U2FsdGVkX1
        2
    U2FsdGVkX1  
       2020 年 12 月 31 日
    fetch 已经高级了吧,上面提到的这些封装意义也不大吧
    而且对于请求库来说,兼容性比较重要,有 xhr 封装为啥还要再造个轮子
    nigelvon
        3
    nigelvon  
       2020 年 12 月 31 日   ❤️ 1
    老版本 ios 不兼容。蛋疼的紧。
    mknightoy
        4
    mknightoy  
       2020 年 12 月 31 日
    楼上已经说了主要是兼容性,另外 fetch 已经算高度封装了没必要在多此一举
    az22c
        5
    az22c  
    OP
       2020 年 12 月 31 日
    @U2FsdGVkX1 “fetch 已经很高级”,这一点我是认为不对的。上面说的小功能点比如 cookie 相关的,还是很有必要的封装的。

    封装起来,搞一个项目可以收割 github star 。比如有些人就是后端开发知识懂一点点客户端开发,想搞个顺手的东西代码一粘贴就能完成请求,不用遭遇调试这些缺少的小功能点。所以封装一个还是挺爽的?
    codehz
        6
    codehz  
       2020 年 12 月 31 日 via Android
    因为 fetch 功能少,连个取消请求都要等草案
    可以说没有任何优势(
    zy445566
        7
    zy445566  
       2020 年 12 月 31 日
    用了 fetch 就不需要 axios 、swr 了
    zy445566
        8
    zy445566  
       2020 年 12 月 31 日
    我的意思是 fetch,自己稍微封装下就能用,没必要使用别人封装的 fetch 库
    noe132
        9
    noe132  
       2020 年 12 月 31 日   ❤️ 1
    不支持取消请求,不支持获取上传 /下载进度
    buhi
        10
    buhi  
       2020 年 12 月 31 日
    为什么基于浏览器 + - * / 的封装库这么少
    一个道理
    Benno
        11
    Benno  
       2021 年 4 月 18 日 via Android
    有了。拿去使,不好用提!
    https://github.com/Benno-Wu/SimplifiedFetch
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   2848 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 15:03 · PVG 23:03 · LAX 07:03 · JFK 10:03
    ♥ Do have faith in what you're doing.