首页
学习
活动
专区
圈层
工具
发布

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

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

2K30
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    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,而不是直接看代码就懂 写代码不是比谁用的技术栈多,而是比谁的代码改起来最顺手。

    18710

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

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

    24310

    为什么我不再用Redux了

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

    3.4K20

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

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

    3.1K30

    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从数据层解耦出来,并随时迁移到任何数据层上。 ?

    88320

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

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

    33310

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

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

    4.5K10

    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.2K20

    我在大厂写React,学到了什么?

    前言 我工作中的技术栈主要是 React + TypeScript,这篇文章我想总结一下如何在项目中运用 React 的一些技巧解决一些实际问题,本文中使用的代码都是简化后的,不代表生产环境。...以 URL 为数据仓库 在公司内部的后台管理项目中,无论你做的系统面向的人群是运营还是开发,都会涉及到分享,那么保留「页面状态」就非常重要了。...在传统的状态管理思路中,我们需要在代码里用redux、recoil等库去做一系列的数据管理,但是如果把 URL 后面的那串 query 想象成数据仓库呢?...经过处理后,转变为这样: import React from 'react'; import { useI18n } from 'react-intl'; import { Button, Toast...以及 AST 处理各种各样的边界情况,肯定要复杂的多,以上只是简化版的思路。

    1.8K10

    我在工作中写React,学到了什么?

    前言 我工作中的技术栈主要是 React + TypeScript,这篇文章我想总结一下如何在项目中运用 React 的一些技巧解决一些实际问题,本文中使用的代码都是简化后的,不代表生产环境。...以 URL 为数据仓库 在公司内部的后台管理项目中,无论你做的系统面向的人群是运营还是开发,都会涉及到分享,那么保留「页面状态」就非常重要了。...在传统的状态管理思路中,我们需要在代码里用redux、recoil等库去做一系列的数据管理,但是如果把 URL 后面的那串 query 想象成数据仓库呢?...babel-ast-practise/blob/master/i18n.js 这样的一段源代码: import React from 'react'; import { Button, Toast, Popover...以及 AST 处理各种各样的边界情况,肯定要复杂的多,以上只是简化版的思路。

    1.2K30
    领券