文档建议反馈控制台
首页
学习
活动
专区
圈层
工具
MCP广场
文章/答案/技术大牛
发布

使用React-Query解决接口请求的麻烦事

一些状态管理库的弊端 许多状态管理库，比如redux，可以很流畅的管理页面的状态，也有处理副作用的能力，但往往不能很好的处理服务端的状态，因为处理服务端的状态，通常还包括： 缓存 将对同一数据的多个请求消除为一个请求...在后台更新“过期”数据 知道数据何时“过期” 尽快反映数据更新 性能优化，如分页和延迟加载数据 管理内存和服务器状态的垃圾收集 使用结构共享记忆查询结果 直到React-Query的出现，上面的问题都变得迎刃而解...它提供了几个简单的Hooks，借助它们可以很轻松的完成对后端数据的增删改查等操作，无需再写繁琐的数据拉取和状态判断等代码。...数据预获取 有时候我们不需要整个页面loading来等待数据加载，我们更希望在用户操作之前就拉取完数据，比如用户hover详情链接，而不是点击详情的时候。...那我们可以使用queryClient的prefetchQuery方法，提前拉取到用户可能会访问的数据，并加入到缓存中，由于不需要监听服务端状态等，所以这个方法会比useQuery高效许多。

2.1K30

2026年React数据获取的第六层：从自己写缓存到用React Query——减少100行代码的秘诀

——我们用React Query将之前手写的所有复杂逻辑浓缩成几行代码。...从100行代码到10行代码 某个创业团队的应用，用户管理界面需要： 需求清单： ✅ 加载用户列表 ✅ 缓存用户数据 ✅ 用户修改时更新缓存 ✅ 支持分页 ✅ 处理加载/错误状态 ✅ 自动重试失败的请求...：15 行，而且自动处理了： ✅ 缓存 ✅ window失焦后台更新 ✅ 自动重试 ✅ 防止重复请求 ✅ 错误处理 代码减少：80行 → 15行（减少81%） 这不仅仅是少写代码，更重要的是少维护代码。...❌ 很难 ✅ 容易 性能： 自己写 ← → 用React Query ❌ 容易优化失败 ✅ 优化好的 何时用React Query 场景 建议 简单的一次性fetch ❌ 不需要...最后的话 这一篇是一个重要的分水岭——从"自己管理所有逻辑"到"用框架做正确的事"。 很多初级开发者被困在自己写缓存的泥沼里，而不知道React Query这样的库能简化90%的工作。

15410
    • 您找到你想要的搜索结果了吗？
    是的
    没有找到

    react-query从拒绝到拥抱

    获得了{starCount}颗星; } 复制代码 看到以上新增的管理loading和err状态的代码，你的负担是否大了很多？...导致你的组件更容易出bug，很大可能会造成你忘记去修改或重置它们的状态，因为这些状态分布零散，同时这也会造成将来的代码是多么难以维护和扩展，这会是一场噩梦。...}颗星 ); } 复制代码 在这里使用useQuery，此刻这个请求拥有了自动获取数据，管理请求状态，错误重试，窗口焦点自动获取数据，缓存等，它的第1个参数是一个唯一的key，名字有意义就好...最后它会返回一个结果，结果里面包含请求的数据，加载状态，错误等，这样这个请求就把所有这些状态串联起来，而不是一堆散乱的状态，突然逻辑变得清晰了，你只需要根据这些状态处理页面，一切都简单了。...react-query 三大核心概念 Queries useQuery ：发起单个请求 useQueries：发起多个请求 useInfiniteQuery:用于无限加载的列表，非常强大，让构建无限加载组件变得简单

    3.2K31

    我在大型项目中发现的真相

    跨越很多层级的数据共享 比如某个数据需要从根组件传到第 7 层子组件。每一层都要透传，很烦。这时全局状态有意义。 除了这些呢？ 坦白说，90% 的其他状态都不需要。...状态爆炸（数据模型越来越复杂） 维护地狱 用 React Query 就对了： import { useQuery, useMutation } from'@tanstack/react-query'...Redux 代码：从 6000+ 行削减到 400 行（只有购物车状态用 Zustand） 新功能开发速度：提升 40% Bug 数量：下降 60% 页面加载速度：快了 30% 新人上手时间：从一周缩短到两天...因为代码简单了，不需要花时间理解 Redux 的概念。看代码就能懂。 那我现在的项目怎么办？ 不用急着全删。但下次写功能前，问自己三个问题： 1. 这个状态只有当前组件用吗？...value } 一个简单的状态改动需要改 3-4 个文件 新人上手需要花时间学 Redux，而不是直接看代码就懂 写代码不是比谁用的技术栈多，而是比谁的代码改起来最顺手。

    20710

    你的useEffect真的在「同步」吗？为什么React开发者集体掉进了状态管理的陷阱

    useEffect地狱的具体表现 这个根本认知错误衍生出一份无穷的TODO清单，所有这些问题都得手工处理： 加载和错误状态管理：需要额外的isLoading、isError、isSuccess等状态来追踪请求的各个阶段...正确的架构思路 一个成熟的服务端状态管理方案应该： 自动处理缓存：同一时间内对同一数据的多个请求应该只发送一次 智能刷新：决定什么时候数据算「新鲜」，什么时候应该后台重新获取 并发控制：确保不会因为网络波动导致新数据被旧数据覆盖...第三部分：解决方案——TanStack Query的设计哲学 TanStack Query（前身是React Query）的核心创新在于：它不是「另一个全局状态管理工具」，而是专门为服务端状态设计的同步引擎...看起来代码更多了，但这段代码处理了所有边界情况： 用户看不到任何加载中的状态，体验极其流畅 网络请求失败？列表自动恢复原样，用户知道失败了 多个异步操作？...其他时候让系统的staleTime机制自动处理。 总结：从「救火」到「防火」 如果你现在的React代码里充满了复杂的useEffect依赖和状态管理逻辑，那恭喜——你找到了问题所在。

    26610

    使用React Query做为axios请求库的上层封装

    ，我们不仅将数据一锅炖放在全局状态管理上，写法上也使得项目越来越臃肿了（以至于出现后面rematch、dva方案进行简化），我们有没有想过，服务端的状态就不应该放在全局状态管理上，全局状态管理应该专门处理用户交互的中间状态...接下来，就是引出今天的主角 React Query React Query React Query 通常被描述为 React 缺少的数据获取(data-fetching)库，但是从更广泛的角度来看...而 React Query 就是为了解决服务端状态带来的上述问题而出现的，除此之外它还带来了以下特性： 更方便地控制缓存 把对于相同数据的多个请求简化成一个 在后台更新过期数据 知道数据什么时候会「过期...」 对于数据的变化尽可能快得做出响应 分页查询和懒加载等请求性能优化 管理服务器状态的内存和垃圾回收 通过结构共享（structural sharing）来缓存查询结果 请求中间态处理 function...借助于这样的特性，我们就可以将所有跟服务端进行交互的数据从类似于 Redux 这样的状态管理工具中剥离，而全部交给 ReactQuery 来管理。

    3.1K30

    为什么我不再用Redux了

    如果我们不再在前端代码中管理后端状态，而只是将其视为需要定期更新的缓存会怎么样呢？将前端视为从缓存读取内容的简单显示层后，我们的代码就会变得更加易用，并且更适合纯前端开发人员阅读。...、缓存和无效化，只是加载数据并在加载时将其存储在全局存储中而已。...https://react-query.tanstack.com/docs/overview 现在，无论需要什么数据，你都可以将 useQuery hook 与你设置的唯一键（在本例中为“todos”）...React Query 和 SWR 大约是在同一时间开始开发的，并且以积极的方式相互影响。在 react-query 文档中也对这两个库进行了彻底的比较。...处理完应用程序的数据获取 / 缓存部分后，前端几乎没有全局状态可处理。可以使用 Context 或 useContext+useReducer 处理剩下的少量内容，代替 Redux 的作用。

    3.4K20

    2026年前端的痛点：90%开发者还在错误地处理数据获取——从网络模型到React生产级方案

    状态码与错误处理——你的代码会掩盖bug 为什么光看status不够 // ❌ 常见的"听起来对"但实际错误的处理 fetch(url) .then(response => { console.log...，他们早期一个重要功能，因为没有正确处理401响应，导致用户token过期后继续发送请求，造成了严重的审计日志记录问题。...从3行到20行，但这20行能防止内存泄漏、避免ghost state更新、正确处理错误、显示加载状态。...} } } 配合React Query实现的现代方案 // ✅ 2026年推荐的做法：使用TanStack Query（原React Query） import { useQuery }...[ ] 是否有降级方案（网络不可用时的默认行为）？ [ ] 是否向用户展示了友好的加载/错误状态？ 下一步：该学什么？ 这篇文章只是起点。

    18410

    React 应用架构实战 0x5：集成 API 到应用中

    我们将学习如何在客户端和服务器上获取数据，对于 HTTP 客户端，我们将使用 Axios，并使用 React Query 库来处理获取到的数据，它允许我们在 React 应用程序中处理 API 请求和响应...Query React Query 是一个很好的处理异步数据的库，可以将数据在 React 组件中使用。...# 为什么使用 React Query React Query 是一个很好的处理异步远程状态的选择的主要原因是它可以为我们处理许多事情。...我们可以看到这里有一定量的重复代码： 需要定义相同的data、error和 loading 状态 必须相应地更新不同的状态 数据在我们离开组件时立即被丢弃 如果使用 React Query，我们可以使用...，消费者不需要担心存储数据或处理加载和错误状态；一切都由 React Query 处理。

    2K20

    同学，请专业点，用Hooks解耦UI组件吧

    这是否意味着同样的渲染逻辑要重复写n次呢？ 解耦数据请求 怎么可能，让我们将数据请求部分抽离为一个自定义hook——useSomeData。...error && someData && {/* INSERT ANOTHER AMAZING UI */}} React.Fragment> ); }; 复用代码挺棒的...此时只需要简单的修改下useSomeData，完全不需要改动业务组件： import React, { useEffect } from 'react'; import { useDispatch, useSelector...就像经典的依赖倒置原则（SOLID中的D）。尽管并非面向对象，但我们定义了一个抽象接口，并基于其实现了该接口的类。 useSomeData实际上为使用他的业务组件提供了一个接口。...开发者不需要关心useSomeData的实现原理，只需要关注接收到的数据、加载状态、错误信息即可。 理论上来说，只要定义合适的接口，就能将UI从数据层解耦出来，并随时迁移到任何数据层上。 ?

    89120

    2025年React状态管理的残酷真相

    你是否还在为庞大的Redux项目维护而头疼？或者正在新项目中纠结应该选择Zustand还是Redux？本文将彻底拆解2025年React状态管理的真实困境——答案可能会颠覆你的认知。...第一个残酷真相：90%的项目其实不需要Redux 先问你一个问题：你项目中的Redux代码到底在干什么？...真相二：状态应该按"场景"分类而不是"位置" 让我们把应用的"状态"重新分类。关键不是问"这个状态放在哪里"，而是问"这个状态是什么性质的"。性质不同，处理方案完全不同。 1....远程状态（Remote State）：大头来了 这才是你Redux代码的90%所在。 想象一个典型场景：用户打开商城页面，需要加载商品列表。...，但处理了： ✅ API数据加载和缓存 ✅ 错误处理和加载态 ✅ URL同步（compare参数可以复制链接分享） ✅ 组件内部UI切换状态 ✅ 全局用户数据 ✅ 购物车和收藏逻辑 常见问题解答 Q:

    39610

    为什么你的asyncawait代码还在隐藏bug？从Headers到useEffect的完整指南

    你有没有遇到过这样的错误？...，就应该考虑用React Query或SWR： // 使用TanStack Query（React Query） import { useQuery } from'@tanstack/react-query...100+ 用React Query: ├─ 开箱即用的缓存 ├─ 自动去重和合并请求 ├─ 内置智能重试 ├─ 内置加载状态管理 ├─ 代码行数：10-20 总结：你现在应该知道的事 三个"意外发现...调试等功能 useEffect是bug的温床 — 无限循环、内存泄漏、竞态条件都潜伏在这里 2026年前端开发者的检查清单 [ ] 我的async/await代码有没有不必要的串行执行？...[ ] 对于复杂的数据获取，我是否考虑用React Query而不是自己写？ 【关注前端达人，让技术成为竞争力】 如果这篇文章对你有启发，强烈推荐关注微信公众号《前端达人》。

    13110

    React 中请求远程数据的四种方法

    但是这个示例忽略了加载状态，错误处理，声明和设置相关状态等。在现实世界中， HTTP 调用看起来更像这样。...如果我要进行许多 HTTP 调用，我不想为每个调用重复和维护大约 20 行代码。内联调用让你的代码变得很丑。...看一下我们要解决的一些问题： 声明加载状态 声明错误状态 将错误打印到控制台 检查响应是否通过返回 200 response.ok 如果响应正常，将响应转换为 json 并返回 promise 如果响应不正确...，抛出错误 在 finally 中隐藏加载状态，以确保 Loading 即使发生错误也被隐藏 声明一个空的依赖项数组，以便 useEffect 只运行一次 这只是一个简单的示例，它忽略了许多其他相关问题...而且每个 HTTP 调用都需要很少的代码： import React from "react"; import { getUsers } from ".

    4.6K10

    129.精读《React Conf 2019 - Day2》

    中状态： }> 与此同时，实际业务组件中的取数也不需要担心取数是否正在进行中，...包裹即可，此时的 fallback 含义是组件加载异常的错误状态： function Home(props) { return ( 加载 假设 Composer 与 NewsFeed 组件内部都通过 useQuery 取数，那么并行取数时加载机制如下： 这可能有两个问题：组件内部加载顺序不统一与组件间加载顺序不统一。...相比之下，普通的 useQuery 函数存在下面几个问题： 由于取数过程存在状态变化，可能导致组件在 “取数无意义” 状态下重新渲染多次。 可能取数还未完成就触发重渲染。...没有取消的机制，没有清除结果的机制。 没有办法唯一标识组件。

    1.5K10

    React 中请求远程数据的四种方法

    但是这个示例忽略了加载状态，错误处理，声明和设置相关状态等。在现实世界中， HTTP 调用看起来更像这样。...如果我要进行许多 HTTP 调用，我不想为每个调用重复和维护大约 20 行代码。内联调用让你的代码变得很丑。...看一下我们要解决的一些问题： 声明加载状态 声明错误状态 将错误打印到控制台 检查响应是否通过返回 200 response.ok 如果响应正常，将响应转换为 json 并返回 promise 如果响应不正确...，抛出错误 在 finally 中隐藏加载状态，以确保 Loading 即使发生错误也被隐藏 声明一个空的依赖项数组，以便 useEffect 只运行一次 这只是一个简单的示例，它忽略了许多其他相关问题...而且每个 HTTP 调用都需要很少的代码： import React from "react"; import { getUsers } from ".

    2.7K30

    React 设计模式 0x6：数据获取

    GraphQL 查询总是返回可预测的结果，使用 GraphQL 的应用程序速度快且稳定，因为它们控制获取的数据，而不是由服务器来控制。...状态管理是另一种在 React 应用程序中缓存数据并使用它的方法。...此外，您可以获取数据并将其存储在 React 应用程序状态中。 # React Query React Query 是一个库，用于处理 React 应用程序中的数据获取和管理。...它提供了许多有用的功能，如数据缓存、自动重试、请求取消和突变。 React Query 的目标是提供一个简单的 API，让数据获取和管理变得更加容易，并且可以与现有的代码库集成。...通过使用 React Query，开发者可以快速地处理数据获取和管理，同时保持 React 应用程序的高性能和可伸缩性。

    2.3K20
    点击加载更多

    相关资讯

    热门标签

    更多标签

    活动推荐

      运营活动

      活动名称
      广告关闭

      腾讯云开发者

      扫码关注腾讯云开发者

      扫码关注腾讯云开发者

      领取腾讯云代金券

      热门产品

      热门推荐

      更多推荐

      Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有

      深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 粤公网安备44030502008569号

      腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号

      领券