用户交互的中间状态 服务端状态 在陈年的老项目中，通常用Redux、Mobx这样的「全局状态管理方案」无差别对待他们。...事实上，他们有很大区别： 用户交互的中间状态 比如组件的isLoading、isOpen，这类「状态」的特点是： 以「同步」的形式更新 「状态」完全由前端控制 「状态」比较独立（不同的组件拥有各自的isLoading...「缓存」的性质不同于「状态」 不同于交互的中间状态，服务端状态更应被归类为「缓存」，他有如下性质： 通常以「异步」的形式请求、更新 「状态」由请求的数据源控制，不由前端控制 「状态」可以由不同组件共享...当请求成功后，会触发onSuccess回调，回调中调用queryCache.invalidateQueries，将userData对应的query缓存置为invalidate。...这样，React-Query就会重新请求userData对应query的数据。 总结 通过使用React-Query（或SWR）这样的数据请求库，可以将服务端状态从全局状态中解放出来。
目前，当涉及到管理控制台中的用户身份验证时，应用程序仍然依赖于测试数据。在本节中，我们将构建应用程序的身份验证系统，允许用户认证并访问受保护的资源在管理控制台中。...除了响应数据之外，还将附加一个 httpOnly cookie，从此时起用于身份验证请求 每当用户进行身份验证时，我们将从响应中的用户对象存储在 react-query 缓存中，并使其对应用程序可用 由于身份验证是基于...cookie 的，带有 httpOnly cookie，因此我们不需要在前端处理身份验证令牌，任何后续请求都将自动包括令牌 调用 /auth/me 接口将处理页面刷新后的用户数据持久化，该接口将获取用户数据并将其存储在相同的...react-query 缓存中 为了实现此系统，我们需要以下内容： 认证功能（登录、注销和访问已认证用户） 保护需要用户进行身份验证的资源 # 功能实现 # 登录 // src/features/auth...我们希望确保任何这样的尝试都将重定向用户到登录页面。为此，我们要创建一个组件，它将包装受保护的资源，并允许用户查看受保护的内容，只有在他们经过身份验证的情况下才能访问。
return } 这是一个组件拉取服务端数据的简单例子，在组件中，我们简单拉取了一个接口的数据，并监听接口的状态，根据状态来更新不同的UI。...key值，也可以在数组中，写入多项如：['repoData', '1'],这样React-Query在使用的时候会自动把它拼接为/repoData/1，这个在缓存用户访问过的页面时，非常有用。...queryFn：用于请求的方法，如果在QueryClient中配置了，这里可以不必再写，需要返回请求完成后所处理的数据。...onSuccess：接口调用成功后的回调 onError: 失败的回调 返回的数据和useQuery基本是相同的，这里的mutate则是触发更改的方法，如果我们想执行useMutation中传入的方法...，并在屏幕一角提供一个切换按钮以显示和隐藏devtools 在devtools中我们可以直观的看到已经缓存下来的数据和整个项目的配置，以及各个接口的状态等。
它是一个针对 React 应用的状态管理器，可以简化许多任务，例如处理 HTTP 请求状态、在客户端保存数据以防止多次请求、使用 hooks 共享数据等等。...通过它，你可以以一种非常简单的方式从源中检索数据并处理此请求的所有状态。...突变 伙计们，是时候谈论 React Query 中的第二个核心概念了，即突变。 这是什么？ 突变是用户可以在你的应用程序中执行的操作，你可以将突变想象成更改或创建某些东西的操作。...在你的应用程序中使用该组件的好处在于，它允许在运行时查看 ReactQuery 中发生的情况。你可以检查状态中保存的数据，不同的查询有多少应用程序部分使用等等。...，hook 返回一个简单的函数，该函数清除用户状态中的值并导航到登录页面。
react-query是一位数据获取专家，能够智能管理请求的一切内容，包括数据、状态、缓存，更新等，基于Hooks。...为了进一步增强应用和体验，比如网络错误自动重试，为了防止用户看到的是旧的数据，你需要增加窗口焦点时重新自动获取数据等，可以看出如此发展下去，组件需要管理的状态越来越多，你也会越来越力不从心，状态的增多，...导致你的组件更容易出bug，很大可能会造成你忘记去修改或重置它们的状态，因为这些状态分布零散，同时这也会造成将来的代码是多么难以维护和扩展，这会是一场噩梦。...react-query 三大核心概念 Queries useQuery ：发起单个请求 useQueries：发起多个请求 useInfiniteQuery:用于无限加载的列表，非常强大，让构建无限加载组件变得简单...下面来看下Queries的配置对象 Queries options 配置对象就是第3个参数，它是一个对象，这个配置对象在useQueries，useInfiniteQuery中也相同,这个对象有数十个参数可供配置
在之前，了解了如何设置模拟 API，而在本节中，将学习如何通过应用程序消费 API。当我们提到 API 时，指的是 API 后端服务。...我们将学习如何在客户端和服务器上获取数据，对于 HTTP 客户端，我们将使用 Axios，并使用 React Query 库来处理获取到的数据，它允许我们在 React 应用程序中处理 API 请求和响应...，可以将数据在 React 组件中使用。...我们可以看到这里有一定量的重复代码： 需要定义相同的data、error和 loading 状态 必须相应地更新不同的状态 数据在我们离开组件时立即被丢弃 如果使用 React Query，我们可以使用...React Query 的另一个好处是它的缓存机制。对于每个查询，我们需要提供相应的查询键，用于将数据存储在缓存中。 这也有助于请求的去重。
，我们不仅要请求数据，还要处理相应的loading,error这些中间态，这类通用的中间状态处理逻辑可能在不同组件中重复写很多次。...另外，现在的前端项目特别是单页面应用，会使用Flux、Redux、Mobox等状态管理库，会把组件间共享的数据都存放在状态管理库中，这些可以分为两类，一类是用户交互的中间状态,比如isLoading,isClose...，我们不仅将数据一锅炖放在全局状态管理上，写法上也使得项目越来越臃肿了（以至于出现后面rematch、dva方案进行简化），我们有没有想过，服务端的状态就不应该放在全局状态管理上，全局状态管理应该专门处理用户交互的中间状态...解决了什么问题 服务端状态有以下特点： 存储在远端，本地无法直接控制 需要异步 API 来查询和更新 可能在不知情的情况下，被另一个请求方更改了数据，导致数据不同步 现有的状态管理库（如 Mobx、Redux...借助于这样的特性，我们就可以将所有跟服务端进行交互的数据从类似于 Redux 这样的状态管理工具中剥离，而全部交给 ReactQuery 来管理。
内联写法 集中管理 自定义 Hook react-query/swr 注意：在本文中，我将使用 fetch 进行 HTTP 调用，但是这些模式也适用于 Axios 之类的替代方法。...但是这个示例忽略了加载状态，错误处理，声明和设置相关状态等。在现实世界中， HTTP 调用看起来更像这样。...看一下我们要解决的一些问题： 声明加载状态 声明错误状态 将错误打印到控制台 检查响应是否通过返回 200 response.ok 如果响应正常，将响应转换为 json 并返回 promise 如果响应不正确...，抛出错误 在 finally 中隐藏加载状态，以确保 Loading 即使发生错误也被隐藏 声明一个空的依赖项数组，以便 useEffect 只运行一次 这只是一个简单的示例，它忽略了许多其他相关问题...service 是最流行的术语，我在下面也讨论了很多好的替代名称，如 client 或 api。 要点是，所有的 HTTP 调用都是通过纯 JavaScript 函数处理的，存储在一个文件夹中。
作为前端缓存库中的佼佼者，React-Query一直拥有大量受众，官方推出的React-Query课程都卖出了8w+份。但就是这样一款能打的产品，居然有被淘汰的风险，这究竟是为什么？...类似的，在全栈框架Next.js中，也推荐在CSR（客户端渲染）时使用同团队开发的缓存库SWR用于数据的同步操作。但是，随着SSR框架开始支持序列化数据，这一切都变了。...序列化数据的意义在React中，对于如下JSX：const name = "卡颂";你好，{name}在传统SSR中，经由后端处理后，传递给前端的是如下HTML结构：你好，卡颂</p...在React Server Component中，同样的JSX结构经由后端序列化后，传递给前端的是Content-Type为text/x-component的如下数据结构：0:["$@1",null]1...比如，在如下Next.js代码中，AddToCart组件在前端渲染，addItem方法的逻辑是操作数据库的后端逻辑：import { cookies } from 'next/headers'; export
作为前端缓存库中的佼佼者，React-Query一直拥有大量受众，官方推出的React-Query课程都卖出了8w+份。 但就是这样一款能打的产品，居然有被淘汰的风险，这究竟是为什么？...类似的，在全栈框架Next.js中，也推荐在CSR（客户端渲染）时使用同团队开发的缓存库SWR用于数据的同步操作。 但是，随着SSR框架开始支持「序列化数据」，这一切都变了。...序列化数据的意义 在React中，对于如下JSX： const name = "卡颂"; 你好，{name} 在传统SSR中，经由后端处理后，传递给前端的是如下HTML结构： 你好...在React Server Component中，同样的JSX结构经由后端序列化后，传递给前端的是Content-Type为text/x-component的如下数据结构： 0:["$@1",null]...比如，在如下Next.js代码中，AddToCart组件在前端渲染，addItem方法的逻辑是操作数据库的后端逻辑： import { cookies } from 'next/headers';
而前者包含一个完整的React全栈论坛项目： 用户登录页面 作者通过这个项目举例，展示了与「项目架构」相关的13个方面的内容，比如： 文件目录该如何组织 工程化配置有什么推荐 写业务组件时该怎么规范...怎么做状态管理 项目中并不是所有状态都需要保存在「中心化的store」中，需要根据状态类型区别对待。...组件状态 对于组件的局部状态，如果只有组件自身以及他的子孙组件需要这部分状态，那么可以用useState或useReducer保存他们。...应用状态 与应用交互相关的状态，比如「打开弹窗」、「通知」、「改变黑夜模式」等，应该遵循「将状态尽可能靠近使用他的组件」的原则，不要什么状态都定义为「全局状态」。...欢迎在评论区交流项目架构中的最佳实践。 参考资料 [1] Bulletproof React: https://github.com/alan2207/bulletproof-react
关注 ▲1分钟前端▲ 和百万前端精英，一起向上生长 当聊到React状态管理方案，很多人第一反应是Redux。...如果没使用「状态管理」方案，常见方式是请求数据后保存在组件state中，如： function App() { const [data, updateData] = useState(null);...」方案如Redux，会将请求的数据序列化后保存在「全局状态」中。...用户交互的中间状态 交互的中间状态，比如isLoading、isOpen，同样保存在组件内部。 当可复用组件、或状态需要跨组件层级传递，通常使用Context API。...对于缓存，常见的需求是： 数据状态，加载中？加载完成？发生错误？ 缓存失效后的更新 复用缓存数据 在React技术栈，SWR、react-query都是优秀的解决方案。
，我们整个项目采用的是 react-query 进行 url 管理，在它的 API 中有能够返回 isLoading 状态的 hook 也就是我们的数据请求的完成状态，这也让我们可以利用这个 isLoading...同时会将 form 表单中的数据作为参数，因此我们采用 useMutateProject 这个 hook 来将数据维护到 url 中 const useMutateProject = editingProject...实现编辑，创建功能 我们在点击编辑按钮时，首先需要弹出 modal 编辑信息点击保存后，才需要调用发送请求 上代码 首先先处理 modal 的显示和关闭 （截取下拉框的关键代码）我们在点击编辑按钮时，会触发...num 的高端操作，其实就是一个转化成 boolean 类型的方法 接着我们就可以在 columns 中使用这个 Pin 组件了，在星星状态改变时调用编辑方法，改变数据中的 pin 状态 {...useConfig 来编写这些生命周期函数 在这个 hook 中我们使用了大量的 any ，无关大雅 我们在成功、提交、失败中设置了相应的回调，来处理不同的请求情况 // 乐观更新,用来生产代码的 hook
，将逻辑分开来，我们通过 props 向这两个组件传递了 onError 方法，在组件中可以通过调用这个方法来设置 error 状态的值，再展示到页面上 在这里值得我们注意的是，和类式组件不同，函数式组件会默认的接收...，我们只需要用 styled(组件名) 即可 对于登录和注册页面，采用的是 Antd 中的 Form 表单实现的，在控制好盒子大小后，基本不需要过多的布局 <Form onFinish={handleSubmit...，这样代码看起来思路更加清晰 三、编写 auth-provider 文件 我们在这个文件中来处理我们需要发送的相关请求，首先，由于我们需要实现刷新后仍保持登录状态的效果，我们需要设置 token ，并且对于...()) }) 在组件刚挂载时，我们先检查是否存在 token 如果有，我们就对他进行自动登录 // 保持用户登录状态，在组件挂载的时候就调用 const bootstrapUser = async...中的 error 状态，显示在页面当中 总结 在这个登录注册页面当中，我们可以学到以下几点 context 状态管理 custom hook 在 react 中的强大威力 当 custom hook
然而，当组件重新渲染时，这些数据并不总是需要重新计算或重新获取。有几种方法可以在 React 中实现数据缓存。...useCallback，允许您对耗费性能的函数进行记忆化，以避免在每次重新渲染时调用它们 只需传入一个函数和一个依赖数组，useCallback 将仅在依赖中的一个值发生变化时重新计算记忆化的函数 import...状态管理是另一种在 React 应用程序中缓存数据并使用它的方法。...从 API 缓存的数据可以存储在我们的状态管理中，然后在我们的应用程序中全局使用。尽管数据被缓存，但在刷新页面时，它将丢失数据，需要重新获取。...此外，您可以获取数据并将其存储在 React 应用程序状态中。 # React Query React Query 是一个库，用于处理 React 应用程序中的数据获取和管理。
Redux 是 React 生态系统中的革命性技术。它使我们能够在全局范围内存储不可变数据，并解决了在组件树中 prop-drilling 的问题。...现在，前端开发中的很大一部分负担来自于我们的全局存储的维护工作，我们还要确保这些存储不会遭受状态错误、数据非规范化和陈旧数据的困扰。...如果我们不再在前端代码中管理后端状态，而只是将其视为需要定期更新的缓存会怎么样呢？将前端视为从缓存读取内容的简单显示层后，我们的代码就会变得更加易用，并且更适合纯前端开发人员阅读。...https://react-query.tanstack.com/docs/overview 现在，无论需要什么数据，你都可以将 useQuery hook 与你设置的唯一键（在本例中为“todos”）...React Query 和 SWR 大约是在同一时间开始开发的，并且以积极的方式相互影响。在 react-query 文档中也对这两个库进行了彻底的比较。
举个例子，下述例子中，当fetchNote执行异步请求时，会由包裹Note的Suspense组件渲染「加载中状态」。 当请求成功时，会重新渲染，此时note数据会正常返回。...： 当Note组件首次render，fetchNote发起请求，会throw promise，打断render流程 以Suspense fallback作为渲染结果 当promise状态变化后重新触发渲染...use的存在就是为了替换上述流程。 与当前React中已经存在的上述「promise流程」不同，use仅仅是个「原语」（primitives），并不是完整的处理流程。...而在React中，更新流程是从根组件开始的，所以当数据返回后，更新流程是从根组件从头开始的。 改用async await的方式势必对当前React底层架构带来挑战。...比如，类似SWR、React-Query这样的请求库，就可以结合use，再结合自己实现的请求缓存策略（而不是使用React提供的cache方法） 各种状态管理库，也可以将use作为其底层状态单元的容器。
如果没使用「状态管理」方案，常见方式是请求数据后保存在组件state中，如： function App() { const [data, updateData] = useState(null);...」方案如Redux，会将请求的数据序列化后保存在「全局状态」中。...用户交互的中间状态 交互的中间状态，比如isLoading、isOpen，同样保存在组件内部。 当是可复用组件、或状态需要跨组件层级传递，通常使用Context API。...对于缓存，常见的需求是： 数据状态，加载中？加载完成？发生错误？ 缓存失效后的更新 复用缓存数据 在React技术栈，SWR、react-query都是优秀的解决方案。这里以SWR举例： ?...横向来看，不同类型项目适合不同状态管理： 前端逻辑很重的工具类项目（比如富文本编辑器），需要完备的redo、ondo逻辑，Redux的「单向不可变数据流」是不二的选择。
如果我们需要在组件树中深入访问获取的数据，由于于 useContext 已在服务端组件中被禁用 ，所以无法将 fetch 放置在 React Context 当中。...现在若需要在组件树内的不同点处访问获取的数据，推荐方法是在必要时执行重新获取，再通过 React 执行重复数据删除。 这个 fetch 函数还会默认缓存数据，无论响应缓存标头如何。...恭喜了家人们，React DevTools 无法显示 React 服务端组件的详细信息。我们无法在浏览器中检查组件以查看它使用的具体 props 或子组件。...在我看来，最典型的证明就是 Next.js 文档中的下拉列表——读者可以在 App router（服务端组件）和 Pages router 之间随意选择。...总 结 服务端组件也许的确代表着服务端框架的进步——或者至少在达到生产就绪状态后，应该有其进步意义。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
