ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

SWR 条件数据请求(Conditional Fetching)与依赖请求实战指南

2026/9/14 10:19:01 拓冰建站 浏览量
SWR 条件数据请求(Conditional Fetching)与依赖请求实战指南 SWR 条件数据请求Conditional Fetching与依赖请求实战指南【免费下载链接】nextraSimple, powerful and flexible site generation framework with everything you love from Next.js.项目地址: https://gitcode.com/GitHub_Trending/ne/nextra导读本指南基于 nextra 仓库 中 SWR 官方文档站的《Conditional Fetching》章节源文件位于 examples/swr-site/content/en/docs/conditional-fetching.md系统讲解 SWRReact Hooks 数据请求库中何时发请求、如何按依赖关系发请求的核心能力通过把key设为null或函数来暂停请求、按需触发以及通过函数式key实现数据依赖数据的串行/并行请求编排。读完本文你将掌握条件请求、依赖请求的完整写法、底层判定逻辑以及它们与 Suspense、全局配置组合时的边界行为。背景SWR 的 key 是请求的唯一标识在 SWR 中useSWR(key, fetcher)的key不仅是一个字符串它还是请求的唯一标识与缓存键。官方参数说明见 examples/swr-site/content/en/docs/options.mdxkey可以是一个字符串也可以是函数、数组或null。正是函数与null这两种形态构成了条件请求与依赖请求的全部基础当key是null或函数返回 falsy 值时请求不会发起SWR 保持暂停状态当key是函数时SWR 会调用该函数并把返回值当作真正的 key使用。这意味着发不发请求和请求什么内容都可以被动态计算从而把数据获取的主动权完全交给应用逻辑。一、条件请求Conditional用 key 控制是否发起请求条件请求解决的核心问题是某些数据只有在特定条件下才应该被拉取例如用户尚未登录、页面开关未打开、权限未就绪时。SWR 官方文档给出了三种等价写法全部继承自 conditional-fetching.md// 方式一直接用三元表达式条件不满足时 key 为 null const { data } useSWR(shouldFetch ? /api/data : null, fetcher) // 方式二用函数返回 key条件不满足时返回 falsy 值 const { data } useSWR(() (shouldFetch ? /api/data : null), fetcher) // 方式三让函数抛出异常例如依赖的对象还未加载完成 const { data } useSWR(() /api/data?uid user.id, fetcher)三种方式的共同判定规则是如果 key 为null或作为 key 的函数返回 falsy 值或函数执行时抛出异常SWR 就不会发起请求。具体来说写法触发条件暂停原因key nullshouldFetch为假key 为null无请求key () (cond ? url : null)函数返回null/undefined/false返回值 falsykey () url user.iduser尚未加载访问user.id抛错函数抛出异常第三种写法看似报错实则是 SWR 依赖请求机制的核心——通过抛异常来声明依赖未就绪从而暂停下游请求。这一点在下一节展开。从实现角度可以印证conditional-fetching在 SWR 文档站中被归类为 Conditional Data Fetching位于Getting Started分组中属于 SWR 基础 API 的进阶用法其姊妹文档>function MyProjects() { const { data: user } useSWR(/api/user) const { data: projects } useSWR(() /api/projects?uid user.id) // 传入函数时SWR 会把函数返回值作为 key。 // 如果函数抛出异常或返回 falsy 值SWR 就知道某些依赖尚未就绪。 // 这里当 user 未加载时访问 user.id 会抛异常。 if (!projects) return loading... return You have projects.length projects }执行流程拆解如下组件挂载时/api/user与/api/projects两个请求会同时并行发起避免串行等待若/api/user尚未返回函数() /api/projects?uid user.id在执行时因访问undefined.id而抛出异常SWR 捕获该异常暂停/api/projects的请求并将其视为依赖未就绪一旦user数据就绪并触发组件重渲染key 函数再次执行成功/api/projects随即自动发起页面最终展示projects.length。这就是官方文档所述在避免瀑布的同时保证最大并行度数据就绪的部分先并行拉取存在依赖的部分自动退化为串行。这也是函数式 key 相比手动await的核心优势——你不需要自己编写等 user 到了再请求 projects的协调逻辑SWR 基于异常/ falsy 的约定替你完成了调度。与 Suspense 组合时的注意点当suspense: true开启时SWR 通常保证渲染时data一定存在但与条件请求或依赖请求组合时如果请求处于**暂停paused**状态data依然可能是undefined。官方在 suspense.mdx 中明确给出了此限制function Profile() { const { data } useSWR(isReady ? /api/user : null, fetcher, { suspense: true }) // 当 isReady 为 false 时data 仍是 undefined }因此在 Suspense 条件请求的组合下渲染逻辑仍需对data做空值兜底不能依赖 Suspense 的数据必然就绪保证。三、实践把条件请求接入全局配置与数据预填条件请求通常不是孤立使用的它与 SWR 的全局配置体系天然互补。以本仓库的 swr-site 示例站点为例examples/swr-site/package.json它通过nextra与nextra-theme-docs搭建多语言文档站文档正文以 MDX 存放在 examples/swr-site/content/en/docs 下其中条件请求文档还提供了完整的西班牙语译本 conditional-fetching.mdes说明该能力是 SWR 官方文档体系中的标准章节。用 SWRConfig 统一 fetcher 与刷新策略虽然条件请求管的是何时发但怎么发通常交给全局配置。官方 global-configuration.md 展示了通过SWRConfig为所有 SWR hook 提供默认 fetcher 与轮询间隔import useSWR, { SWRConfig } from swr function Dashboard() { const { data: events } useSWR(/api/events) const { data: projects } useSWR(/api/projects) const { data: user } useSWR(/api/user, { refreshInterval: 0 }) // 覆盖全局配置 } function App() { return ( SWRConfig value{{ refreshInterval: 3000, fetcher: (resource, init) fetch(resource, init).then(res res.json()) }} Dashboard / /SWRConfig ) }当全局 fetcher 提供后条件请求的useSWR(shouldFetch ? /api/data : null)甚至可以省略 fetcher 参数同时注意refreshInterval会作用于所有 key——如果某个条件请求暂停轮询是否继续取决于其 key 函数是否仍返回 falsy暂停中的请求不会因轮询而意外发起。用 fallback 预填数据配合条件请求实现首屏策略在 SSG/SSR 场景下可以在服务端预取数据后通过SWRConfig的fallback注入客户端useSWR会优先使用预填数据。官方 with-nextjs.mdx 给出了getStaticProps完整示例结合条件请求你可以实现首屏用预填数据渲染后续按条件增量拉取的渐进增强模式。四、从文档站源码看该章节的组织方式本仓库中该文档的工程落地细节可以从 swr-site 示例站点的源码结构得到印证文档路由examples/swr-site/app/[lang]/[[...mdxPath]]/page.tsx通过nextra/pages的generateStaticParamsFor(mdxPath)与importPage(params.mdxPath, params.lang)按语言与路径动态加载 MDX 页面conditional-fetching.md即对应/en/docs/conditional-fetching路由多语言支持文档内容按content/{en,es,ru}/docs分目录存放语言切换由 app/[lang]/layout.tsx 中的i18n配置驱动en、es、ru三种语言其中 es 站点被标注为 RTL 语言见 next.config.ts导航与目录条件请求章节在侧边栏中的标题为 Conditional Data Fetching由 content/en/docs/_meta.tsx 中的conditional-fetching: Conditional Data Fetching声明排在revalidation自动重新验证之后、arguments多参数 key之前与相邻章节共同构成完整的 SWR 数据获取知识体系配套章节与条件请求强相关的姊妹文档包括 options.mdxkey 参数定义、data-fetching.mdxfetcher 机制、global-configuration.md全局配置、suspense.mdxSuspense 兼容性与 mutation.md数据更新读者可按需串联阅读。五、常见问题与排查要点请求一直不发卡在暂停态检查 key 函数是否稳定返回 falsy 或持续抛异常。依赖请求场景下最典型原因是依赖数据接口失败而非慢导致user.id永远无法访问——此时应先排查上游请求的error状态条件请求与轮询冲突全局refreshInterval只对已激活的 key 生效暂停中的 key 不会被轮询唤醒若希望条件满足后立即刷新可配合 mutation.md 中的mutate(key)手动触发重新验证渲染时空值处理暂停态下data为undefined渲染必须做空值兜底如if (!projects) return loading...Suspense 模式下暂停态同样可能返回undefined不能想当然地省略判空key 函数必须是纯函数key 函数应只依赖组件状态与已有数据避免内部产生副作用或使用不稳定随机值否则会导致 key 在每次渲染间变化触发不必要的重复请求。小结条件请求与依赖请求是 SWR 将请求调度抽象进 hook 的经典设计null/falsy/异常三种暂停信号统一了条件不满足的表达函数式 key 则在保持并行度的同时天然实现了依赖排序。本文所有示例与结论均可追溯至仓库内的 conditional-fetching.md 原文及其配套源码读者可直接在 swr-site 示例中替换为自己的接口路径进行验证。【免费下载链接】nextraSimple, powerful and flexible site generation framework with everything you love from Next.js.项目地址: https://gitcode.com/GitHub_Trending/ne/nextra创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考