尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

AutoGPT 前端性能规则解读:用 SWR 实现请求自动去重(client-swr-dedup)

AutoGPT 前端性能规则解读:用 SWR 实现请求自动去重(client-swr-dedup) AutoGPT 前端性能规则解读用 SWR 实现请求自动去重client-swr-dedup【免费下载链接】AutoGPTAutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.项目地址: https://gitcode.com/GitHub_Trending/au/AutoGPT本文基于 AutoGPT 仓库内置的 Vercel React 最佳实践规则client-swr-dedup位于.claude/skills/vercel-react-best-practices/rules/client-swr-dedup.md讲解客户端数据获取中多组件实例重复请求同一接口这一典型问题的成因以及用 SWR 的useSWR、不可变数据封装与useSWRMutation三类模式实现请求去重、缓存与再验证的完整方案。读完后你可以判断自己在 React/Next.js 项目中的数据获取代码是否存在N 个实例发 N 个请求的浪费并能按规则给出可落地的重构路径。规则定位它在整套性能规则体系中处于什么位置client-swr-dedup是 AutoGPT 仓库为 AI Agent 维护代码时注入的一组 React/Next.js 性能规则中的一条。该规则集定义在 SKILL.md 中共收录 8 大类、按影响程度分级的规则完整展开版本则收录在同目录的 AGENTS.md第 4.2 节即为本文主题。按 SKILL.md 中的优先级表规则被划分为 8 个类别client-swr-dedup属于第 4 类优先级类别影响前缀1Eliminating Waterfalls消除瀑布流CRITICALasync-2Bundle Size Optimization包体积优化CRITICALbundle-3Server-Side Performance服务端性能HIGHserver-4Client-Side Data Fetching客户端数据获取MEDIUM-HIGHclient-5Re-render Optimization重渲染优化MEDIUMrerender-6Rendering Performance渲染性能MEDIUMrendering-7JavaScript PerformanceJS 性能LOW-MEDIUMjs-8Advanced Patterns进阶模式LOWadvanced-client-swr-dedup规则文件的 front matter 元数据也印证了它的定位title: Use SWR for Automatic Deduplication impact: MEDIUM-HIGH impactDescription: automatic deduplication tags: client, swr, deduplication,>function UserList() { const [users, setUsers] useState([]) useEffect(() { fetch(/api/users) .then(r r.json()) .then(setUsers) }, []) }这段写法的问题不在于语法而在于状态与请求都是组件私有的无去重如果UserList在同一页面渲染了 3 个实例例如在列表项、侧边栏、弹窗中各出现一次useEffect会在每个实例挂载时各执行一次产生 3 个完全相同的/api/users请求。无缓存组件卸载后再挂载路由跳转、Tab 切换、条件渲染数据必须重新拉取用户会重新经历一次白屏等待。无再验证revalidation数据在组件实例之间不共享任何一处拿到新数据其他地方无从感知。这是手写fetch的固有局限useEffect的副作用绑定在单个组件实例的生命周期上天然不具备跨实例协调的能力。解决方案一useSWR让多实例共享同一次请求规则给出的正确写法import useSWR from swr function UserList() { const { data: users } useSWR(/api/users, fetcher) }关键机制在于useSWR以key即/api/users为维度在缓存层组织请求而不是以组件实例为维度自动去重同一 key 的并发useSWR调用只触发一次网络请求其余实例直接挂接到同一个 in-flight 请求的 Promise 上跨实例缓存先挂载的实例把数据写入缓存后挂载的实例同步读取缓存无需二次请求再验证组件回到前台、路由焦点回归等时机SWR 会按策略触发 revalidation保证各实例最终一致。对比之下反例中N 个实例 N 个请求变成了多实例共享 1 个请求。这也是该规则 impact 标注为 MEDIUM-HIGH 的原因改动量极小一行 hook 替换整段useState/useEffect逻辑收益却是请求数的线性削减。解决方案二不可变数据使用useImmutableSWR对于内容不会变化的接口例如站点配置、静态字典普通useSWR的再验证仍然是浪费。规则为此给出了专门写法import { useImmutableSWR } from /lib/swr function StaticContent() { const { data } useImmutableSWR(/api/config, fetcher) }这里useImmutableSWR来自项目级封装/lib/swr。可以推断该封装的核心是设置revalidateOnFocus: false、revalidateOnReconnect: false、revalidateOnMount: false一类选项把该 key 的数据标记为不可变——一次获取之后只命中缓存、不再发起请求。对配置类、静态内容类接口这相当于把再验证成本直接归零。需要注意的适用前提这种封装是项目内部封装并非 SWR 库本身导出的 API。若你的项目里没有/lib/swr模块要么自行建立该封装一行useSWR加上 immutable 配置的薄包装要么直接以 options 参数方式表达同等语义。解决方案三写操作使用useSWRMutation数据获取去重之外规则还覆盖了**变更mutation**场景import { useSWRMutation } from swr/mutation function UpdateButton() { const { trigger } useSWRMutation(/api/user, updateUser) return button onClick{() trigger()}Update/button }useSWRMutation与普通useSWR的关键区别在于它不会在挂载时自动发起请求而是返回一个trigger函数由用户动作显式触发。规则给出的示例中updateUser作为第二个参数传入对应swr/mutation导出的 mutation 数据获取器点击按钮时调用trigger()执行更新。这一模式的意义在于语义区分——读useSWR自动获取 去重与写useSWRMutation按需触发分别用对应 API 表达避免把 POST/PUT 塞进useEffect造成渲染期副作用写后一致——mutation 完成后可与缓存联动例如更新对应 key 的数据或触发失效使依赖该数据的各useSWR实例自动拿到新值形成写一次、多实例同步刷新的闭环。仓库佐证AutoGPT 前端实际如何做去重与共享规则文档面向的是应然的最佳实践再看 AutoGPT 平台前端autogpt_platform/frontend的实然可以验证同一思想在本仓库的落地形态。从源码结构看当前 AutoGPT 前端并未引入swr依赖。package.json 的依赖清单中数据层方案是tanstack/react-query5.90.6搭配 Next.js 15.5.21 与 React 18.3.1对src/目录的检索也未发现任何useSWR用法。这与规则并不矛盾——client-swr-dedup规则要表达的核心诉求是客户端请求必须有去重与跨实例共享机制而 TanStack Query 正是以queryKey为维度实现同一套去重、缓存、失效语义的等价方案。实际代码可以印证这一点OrgTeamProvider.tsx 通过getQueryClient()拿到全局唯一的 QueryClient在组织org切换时调用queryClient.resetQueries()让所有仍在屏幕上的共享查询统一重新拉取——这正是多实例共享缓存 集中式失效的典型用法源码注释还专门说明了选择resetQueries而非clear()的原因clear()不会通知已挂载的 observer会导致它们永久 pendingcredentials-provider.tsx 通过useQueryClient在凭据变更时做缓存联动更新测试侧如usePreparingStep.test.ts、useUsageIndicator.test.tsx普遍以new QueryClient({ defaultOptions: { queries: { retry: false } } })QueryClientProvider包裹被测 hook并配合 MSW mock handler 验证查询行为——说明客户端数据获取在本仓库有成熟的测试基建可依附。因此把client-swr-dedup应用到本仓库时的正确姿势是对齐语义而非照搬库名如果你在项目中新增模块且已决定采用 SWR按规则的三套模式实施即可如果沿用 AutoGPT 既有的 TanStack Query 技术栈则应以queryKey去重、staleTime/失效策略对应规则中的普通/不可变数据区分、useMutation对应useSWRMutation的场景达成同等效果。关联规则同一套 SWR 思想还能去重全局事件监听器同目录下还有一条姐妹规则 client-event-listeners.mdDeduplicate Global Event Listeners影响 LOW它把去重思想从网络请求延伸到 DOM 事件用useSWRSubscription把 N 个组件实例的window.addEventListener收敛为 1 个全局监听器再通过模块级Map分发回调。两条规则放在一起读可以更完整理解该规则集对客户端重复资源消耗的整体治理思路请求要按 key 去重监听器也要按事件源去重而 SWR 的缓存/订阅抽象正是两者共同的底层机制。落地清单与适用边界结合规则原文与仓库现状给出可直接执行的检查清单扫描反模式在组件代码中查找useEffect内直接fetch且同一接口在多组件复用的写法这是本规则的首要打击对象普通数据→useSWR(key, fetcher)依赖 key 级去重与再验证不可变数据→ 项目级useImmutableSWR封装或等价 options关闭一切 revalidate 开关写操作→useSWRMutation用trigger显式执行杜绝渲染期副作用技术栈已定时若项目如 AutoGPT 前端已用 TanStack Query按等价语义落地即可不要为了贴合规则字面而混入第二套数据层两套缓存并存反而破坏去重的统一性。适用边界说明本文所有规则内容以 client-swr-dedup.md 及其完整版 AGENTS.md 第 4.2 节为准规则中引用的外部官方文档链接遵循仓库链接规范不再列出读者可按 SWR 官方文档自行核对 API 细节。规则示例中的fetcher、updateUser为示意性函数实际项目中需自行实现为带鉴权、错误处理与r.json()解析的请求函数。【免费下载链接】AutoGPTAutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.项目地址: https://gitcode.com/GitHub_Trending/au/AutoGPT创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表