,而且 useEffect 中现在还没有写依赖,如果有时请求中依赖某些状态,那么这里的请求触发时机就会变得没那么可控了。...相同,它们会使用同一个状态,不需要进行重复请求,也不需要额外定义很多的组件 props。...下面是一张使用缓存前后页面渲染流程的对比图: 光看这张图你可能还比较难 get 到使用缓存的好处,下面我讲一个实际的场景: 在我们常见的表格组件中,最后一列往往都是用于一些删除或者编辑操作的,如下图:...的意思就是突变,我们调用 mutate 也就是在显式的告诉 swr 我的数据已经发生变化啦,赶紧给我更新一波。...在写文章的过程中 SWR 发布了新版本 SWR 2.0 发布[5],新增了很多特性,但没有中文翻译,因此我也为它们的文档贡献了一些中文翻译的 PR ,其中也包括了这篇 理解 SWR[6]。
前言 在我动笔写这篇文章的时候,我刚刚从我的项目中删除了最后一行JQuery代码。至于我为何要这么做,请听闰土娓娓道来。前几年我还在想,假如有一天,前端世界里不能再直接操作dom了,我该怎么办?...那么接下来,正文从这开始~ 熟悉闰土的朋友都知道,我是从JQ时代过来的前端,在刚接触react和vue这类MVVM框架的时候,完全可以用一脸懵逼来形容我,最为贴切。...我在想,如果能从一开始学的时候,把之前的开发思路忘掉,就当自己从来没学过编程,以一种空杯心态从零开始学的话,应该会比较快。之前没有考虑到思路转换这一步,走了弯路。...然后在Vue中,el属性绑定根视图的id,data属性定义并初始化v-model、双大括号用到的数据和一些其他数据。methods属性定义在v-on中用到的和一些其他方法。更新界面修改数据实现。...其实两者并没有什么功能上的交集,如果你非要问可不可以用vue来实现jQuery所能实现的功能的话,我只想说,能,并且更加简洁。
Hooks 的威力还不仅如此,上面短短几行代码还自带如下特性: 可自动刷新。 组件被销毁再渲染时优先启用本地缓存。 在列表页中浏览器回退可以自动记忆滚动条位置。...2.3 自定义取数方式 自定义取数逻辑其实分几种抽象粒度,比如自定义取数 url,或自定义整个取数函数,而 swr 采取了相对中间粒度的自定义 fetcher: import fetch from "unfetch... ); } 通过 mutate 可以在本地临时修改某个 Key 下返回结果,特别在网络环境差的情况下加快响应速度。...3.3 初始缓存 当页面切换时,可以暂时以上一次数据替换取数结果,即初始化数据从缓存中拿: const shouldReadCache = config.suspense || !...try 住了,那么 user.id 在 useSWR("/api/user") 没有 Ready 的情况一定会抛出异常,则自动进入 onErrorRetry 逻辑,看看下次取数时 user.id 有没有
假如你果真碰到这个类似的问题,可以考虑先将项目中的node_modules删除掉,然后重新cnpm install安装项目所需的依赖。通常这个情况,就会迎刃而解(不要问为什么,这可能是个偏方)。...说到组件,在项目中,你可能会看到公司前辈写的组件代码,都是以 .vue 为后缀的文件,打开后你会发现它的整体结构分三层,分别定义了三个 tag标签,template,script,style。...前后端分离后,我们前端工程师开发前,需要和后端同学定义好接口信息(请求地址,参数,返回信息等),前端通过 mock 的方式,即可开始编码,无需等待后端接口是否已经准备就绪(是不是感觉前端干的活儿越来越重...开发的时候,写好data 剩下的事情就是 通过异步请求来交互data,UI层绑定事件改变data,在组件间传递data。 后记 在这个MVVM横行的时代,我已经渐渐的忘却了jQuery的存在。...本系列文章还没有结束,下篇,也可能是终结篇,即将来袭!
用户交互的中间状态 服务端状态 在陈年的老项目中,通常用Redux、Mobx这样的「全局状态管理方案」无差别对待他们。...事实上,他们有很大区别: 用户交互的中间状态 比如组件的isLoading、isOpen,这类「状态」的特点是: 以「同步」的形式更新 「状态」完全由前端控制 「状态」比较独立(不同的组件拥有各自的isLoading...如果是需要复用的通用「状态」,通常将其保存在Redux这样的「全局状态管理方案」中。...这样,React-Query就会重新请求userData对应query的数据。 总结 通过使用React-Query(或SWR)这样的数据请求库,可以将服务端状态从全局状态中解放出来。...这为我们带来很多好处: 使用通用的hook处理请求中间状态 多余请求合并 针对缓存的更新/失效策略 Redux等「全局状态管理方案」可以更专注于「前端中间状态」处理 参考资料 [1] SWR: https
我们在使用React进行前端项目开发时经常会使用到SWR作为请求工具以及处理一部分的状态管理。...SWR在接受的数据请求时会对比本地的useContext中是否缓存了对应的Key如果没有缓存的话才会请求,在管理系统中请求回来的数据经常伴随着增删改。...此时如果我们不对之前请求的缓存进行清除也不对网站进行刷新那么在第二次进入页面时可能会因为缓存数据而出现一些BUG,所以我们通常在对数据进行修改后会对指定的Key进行删除,下次再使用时可以重新请求新数据。...参考:SWR Cache SWR再useSWRConfig中导出了cache对象: 图片 我们可以再useSWRConfig中导出cache后使用delete函数对缓存进行删除或者修改(set)...position }).then(res => { if (res.data.success) { message.success(res.data.message); mutate
一、背景 官方提供的spring boot starter的配置项,我们用IDE配置的时候一般都有自动提示的,如下图所示 而我们自己自定义的配置却没有,对开发非常不友好容易打错配置,那这个是怎样实现的呢...二、提示原理 IDE是通过读取配置信息的元数据而实现自动提示的,而元数据在目录META-INF中的spring-configuration-metadata.json 或者 additional-spring-configuration-metadata.json...三、实现自动提示 以我这个自己开发的starter中的自定义配置文件为例,如果自己手动创建这些元数据的话工作量比较大,使用IDEA的话有自动生成功能 3.1....引入依赖spring-boot-configuration-processor 在zlt-swagger2-spring-boot-starter工程中添加以下jar包 ...重新编译项目 项目在重新编译后就会自动生成spring-configuration-metadata.json文件 四、测试 自定义的swagger配置已经能自动提示了 参考资料 https:/
对于 MySQL 慢 SQL 的分析 在之前的文章,我提到过 SQL 调优一般通过下面三个工具: EXPLAIN:这个是比较浅显的分析,并不会真正执行 SQL,分析出来的可能不够准确详细。...但是不能直观的看出来为啥会走错索引,需要通过 OPTIMIZER TRACE 进行进一步定位。但是在进一步定位之前,我想先说一下 MySQL 的 InnoDB 查询优化器数据配置。...即每次更新,随机采集表以及表中的每个索引的 20 页数据,用于估算每个索引的查询消耗是多大以及全表扫描消耗是多大,控制单个表的配置是 STATS_SAMPLE_PAGES(在 CREATE TABLE...这也引出了一个新的可能大家也会遇到的问题,我在原有索引的基础上,加了一个复合索引(举个例子就是原来只有 idx_user_id,后来加了 idx_user_status_pay),那么原来的只按照 user_id...所以最好一开始就能估计出大表的量级,但是这个很难。 结论和建议 综上所述,我建议线上对于数据量比较大的表,最好能提前通过分库分表控制每个表的数据量,但是业务增长与产品需求都是不断在迭代并且变复杂的。
请求缓存 & SWR:设置 options.cacheKey 后开启对请求结果缓存机制,下次请求前会优先返回缓存并在后台重新取数。...自定义请求依赖 利用 useEffect 和自带的 deps 即可。 分页 基于通用取数 Hook 封装,本质上是多带了一些取数参数与返回值参数,并遵循 Antd Table 的 API。...手动触发请求 上一节已经在初始请求时禁用了 manual 开启时的默认取数。...轮询请求 轮询取数在 Fetch 实际取数函数 _fetch 中定义,当取数函数 fetchService(对多种形态的取数方法进行封装后)执行完后,无论正常还是报错,都要进行轮询逻辑,因此在 .finally...并行请求 每个 fetchKey 对应一个 Fetch 实例,这个逻辑在 手动触发请求 介绍的 run 函数中已经实现。
关键在于,我们的前端和后端状态永远不会真正同步,我们最多可以营造一种它们同步的错觉。这是客户端 - 服务器模型的缺点之一,也是为什么我们需要缓存的原因所在。...我相信其中大多数都没有达成目标。有时为了前进。我们需要先退后一步。 如果我们不再在前端代码中管理后端状态,而只是将其视为需要定期更新的缓存会怎么样呢?...https://github.com/Buuntu/awesome-react-query SWR SWR 在概念上与 React Query 几乎一致。...React Query 和 SWR 大约是在同一时间开始开发的,并且以积极的方式相互影响。在 react-query 文档中也对这两个库进行了彻底的比较。...本文提到的这些库代表了我们在单页应用程序中管理状态的方式变革,并且是朝着正确方向迈出的一大步。我期待着看到它们能对 React 社区产生怎样的影响。
在 Vue.js 中引入组件时需要注册,于是打包的入口文件便需是组件注册的函数,按照文档编写如下: import NexmentContainer from "....功能实现 异步数据获取与更新 首先在 React.js 使用了 SWR,其可借助 React Hooks 实现异步数据获取、聚焦时刷新、数据缓存的功能,不通过 WebSocket 来变相实现数据同步。...data, isError: error, }; 在 Vue.js 中有一个新生项目 SWRV 借鉴自 SWR 功能几乎一致,依赖 Composition API。...pageKey ListGet ); return { data, error, mutate, }; } }) 全局配置 在引入...状态数据更新 React 中使用 useState Hook 来在函数组件内创建数据 State 和更新 State 的函数,样例如下: const [resetStatus, setResetStatus
当聊到React状态管理方案,很多人第一反应是Redux。 Redux为什么这么有名,个人观点,2个原因: 出现时间早,当时社区还没有更好的状态管理解决方案 有React核心团队光环加持。...这就又回到了讨论「广度」(使用哪种状态)与「深度」(多深入的使用这种状态管理方案)。 但事实上,这两种状态的特性是不同的。...对于缓存,常见的需求是: 数据状态,加载中?加载完成?发生错误? 缓存失效后的更新 复用缓存数据 在React技术栈,SWR、react-query都是优秀的解决方案。这里以SWR举例: ?... } 让我们来看SWR如何满足如上三个需求: 数据状态:通过useSWR的返回值参数判断请求状态。比如!error && !data代表「请求中」。...复用缓存数据:SWR会以请求url为key,请求对应promise为value缓存数据,达到多个重复请求复用缓存的目的。
Redux为什么这么有名,个人观点,2个原因: 出现时间早,当时社区还没有更好的状态管理解决方案 有React核心团队光环加持。Redux的作者「Dan」开发初版Redux后便加入React团队。...这就又回到了讨论「广度」(使用哪种状态)与「深度」(多深入的使用这种状态管理方案)。 但事实上,这两种状态的特性是不同的。...对于缓存,常见的需求是: 数据状态,加载中?加载完成?发生错误? 缓存失效后的更新 复用缓存数据 在React技术栈,SWR、react-query都是优秀的解决方案。... } 让我们来看SWR如何满足如上三个需求: 数据状态:通过useSWR的返回值参数判断请求状态。比如!error && !data代表「请求中」。...复用缓存数据:SWR会以请求url为key,请求对应promise为value缓存数据,达到多个重复请求复用缓存的目的。
又到了金三银四,今天和大家分享一下之前我面试某大厂时遇到的一道手写题:使用 JS 简单实现一套 SWR 机制。 什么是 SWR 很多同学可能都没听过什么是 SWR,更不用说用代码实现了。...封装之前,先定义一下需要被缓存的数据,那么什么数据需要被缓存呢? 很显然,不就是 请求返回的数据吗。 但与此同时,你也应该想到,如果重复调用函数,最好不要发送多次请求。...所以缓存数据中应该有: 请求返回的数据 当前正在进行中的请求(如果有),避免多次请求 const cache = new Map(); // 缓存数据 async function swr(cacheKey...支持缓存过期时间 在已有缓存能力的基础上,再支持过期时间 cacheTime 就很容易了。...整个流程大致为: 新加入的数据插入到第一项 每当缓存命中(即缓存数据被访问),则将数据提升到第一项 当缓存数量满的时候,将最后一项的数据丢弃 由于面试时间有限,我不推荐大家在面试时继续写了,很容易弄巧成拙
过去 类组件 在React的类组件时代,请求数据的时机经常放在componentDidMount中,然后state中需要有一个变量记录当前是否正在请求接口,在请求的前后需要手动去改变这些状态,大概代码如下...loading状态变量在自定义hook中管理起来,代码示例: const useRequest = (fn, dependencies = []) => { const [data, setData...关于swr这个库的具体分析文章可以查看这篇:精读《Hooks 取数 - swr 源码》 这个Demo中在路由进入过后如果再次进入,数据会直接显示之前请求过的,你会发现这非常像Vue中的keep-alive...带来的效果,这是因为swr这个库在suspense模式下默认做了数据的缓存,如果想要关掉它目前还没在文档中看到相应的配置。...相比,就是在loading的时候向外抛出一个promise,其他并没有什么改变。
过去 类组件 在React的类组件时代,请求数据的时机经常放在componentDidMount中,然后state中需要有一个变量记录当前是否正在请求接口,在请求的前后需要手动去改变这些状态,大概代码如下...在Hook时代我们可以把请求前后的loading状态变量在自定义hook中管理起来,代码示例: const useRequest = (fn, dependencies = []) => { const...,我们可以在视图容器的外层包裹一层Suspense,在内部通过向外throw Promise的方式告知Suspense我们的组件还没有准备好,需要展示Loading状态。...关于swr这个库的具体分析文章可以查看这篇:精读《Hooks 取数 - swr 源码》 这个Demo中在路由进入过后如果再次进入,数据会直接显示之前请求过的,你会发现这非常像Vue中的keep-alive...带来的效果,这是因为swr这个库在suspense模式下默认做了数据的缓存,如果想要关掉它目前还没在文档中看到相应的配置。
内联写法 集中管理 自定义 Hook react-query/swr 注意:在本文中,我将使用 fetch 进行 HTTP 调用,但是这些模式也适用于 Axios 之类的替代方法。...但是这个示例忽略了加载状态,错误处理,声明和设置相关状态等。在现实世界中, HTTP 调用看起来更像这样。...service 是最流行的术语,我在下面也讨论了很多好的替代名称,如 client 或 api。 要点是,所有的 HTTP 调用都是通过纯 JavaScript 函数处理的,存储在一个文件夹中。...但是还有很多我们没有考虑到的点:缓存?、如果客户端的连接不可靠,如何重新获取?你想在用户重新调整标签时重新获取新数据吗?如何消除重复查询? 你可以不断完善这个自定义Hook来完成所有这些操作。...但是,您应该只需要方式4: 方式4:react-query/swr 使用 react-query或swr,可以为我们处理缓存、重试、重复查询等等。我不必维护自己的自定义Hook了。
newstFetchKey.current; let currentFetch = fetchesRef.current[currentFetchKey]; // 如果没有已经存储的请求状态...类,每次调用run的时候会调用fetch实例的run函数,在实例的run函数中做了节流和防抖的处理,并且会触发我们自定义hooks的setFeches从而触发视图更新。...data; export { getCache, setCache }; 从上面代码的注释来看,实现swr能力非常简单,只需要在每次请求的时候将数据存储到全局的缓存对象中,在初始化的时候先从缓存中获取缓存数据渲染到页面...在自定义hooks中如果调用了"setState"或者"dispatch"就会触发整个函数组件的更新,从而能获取到自定义hook中处理后的最新的数据。...hooks让swr的实现变得非常简单,目前优质的swr自定义hooks有本文讲的useRequest和github上star数量很多的useSwr。
杂七杂八一堆丢在 setup 里,我还不如直接用 react” 我的天,3.0 这么搞的话,代码结构不清晰,语义不明确,无异于把 vue 自身优点都扔了 怎么感觉代码结构上没有 2.0 清晰了呢...让我们把zeit/swr的逻辑照搬到 Vue3 中, 看一下swr在 Vue3 中的表现: failed to load...对了,顺嘴一提, use-swr 的威力可远远不止看到的这么简单,随便举几个它的能力: 间隔轮询 请求重复数据删除 对于同一个 key 的数据进行缓存 对数据进行乐观更新 在标签页聚焦的时候重新发起请求...对于意大利面代码: 提取共用的自定义 Hook(在写 React 购物车组件的时候,我提取了 3 个以上可以全局复用的 Hook)。...React Hook 的心智负担已经重的出名了,在我实际的开发过程中,有时候真的会被整到头秃…… 尤其是抽了一些自定义 Hook,deps 依赖会层层传递的情况下(随便哪一层的依赖错了,你的应用就爆炸了
领取专属 10元无门槛券
手把手带您无忧上云