據(jù)請(qǐng)求去重實(shí)踐：用 SWR 統(tǒng)一緩存、去重與重新驗(yàn)證)
后端前端企業(yè)應(yīng)用【免費(fèi)下載鏈接】papermarkPapermark is the open-source DocSend alternative and secure data rooms with built-in analytics and custom domains.項(xiàng)目地址https://gitcode.com/GitHub_Trending/pa/papermark點(diǎn)擊查看免費(fèi)下載導(dǎo)讀本文圍繞 Papermark 項(xiàng)目中前端數(shù)據(jù)請(qǐng)求的最佳實(shí)踐規(guī)則展開講解如何在 React 應(yīng)用中通過 SWR 實(shí)現(xiàn)跨組件實(shí)例的請(qǐng)求自動(dòng)去重deduplication、緩存與重新驗(yàn)證revalidation避免多個(gè)組件同時(shí)掛載時(shí)對(duì)同一 API 接口發(fā)起重復(fù)請(qǐng)求。讀完本文你將掌握從useState useEffect fetch到useSWR的改造方法理解不可變數(shù)據(jù)與變更操作的兩種進(jìn)階用法并了解 Papermark 在 lib/swr 目錄下 40 余個(gè)數(shù)據(jù) hooks 中如何配置dedupingInterval、條件 key 與輪詢刷新直接指導(dǎo)你在真實(shí)項(xiàng)目中落地這套模式。一、問題背景為什么客戶端請(qǐng)求需要去重在 React 應(yīng)用中同一個(gè)數(shù)據(jù)源經(jīng)常被多個(gè)組件實(shí)例消費(fèi)。典型場(chǎng)景包括文檔列表頁同時(shí)渲染多個(gè)卡片組件、分析面板中多個(gè)圖表組件讀取同一份統(tǒng)計(jì)數(shù)據(jù)、數(shù)據(jù)室Dataroom詳情頁中多個(gè)區(qū)塊都需要文檔訪問記錄。如果每個(gè)組件都在useEffect中獨(dú)立發(fā)起fetch請(qǐng)求則 N 個(gè)組件實(shí)例會(huì)向服務(wù)器發(fā)出 N 份完全相同的請(qǐng)求造成重復(fù)網(wǎng)絡(luò)流量同一份數(shù)據(jù)被反復(fù)拉取浪費(fèi)帶寬API 負(fù)載放大后端接口被無意義地打滿尤其在儀表盤類頁面格外明顯數(shù)據(jù)不一致風(fēng)險(xiǎn)各實(shí)例各自維護(hù)一份狀態(tài)刷新時(shí)機(jī)不同步時(shí)界面會(huì)出現(xiàn)短暫差異。Papermark 的這條規(guī)則見 client-swr-dedup.md將其影響等級(jí)標(biāo)為 MEDIUM-HIGH正是因?yàn)樗苯雨P(guān)系到客戶端性能與后端 API 穩(wěn)定性。二、反模式useState useEffect fetch 各自拉取規(guī)則文檔首先給出了需要避免的寫法——每個(gè)組件實(shí)例獨(dú)立發(fā)起請(qǐng)求無任何去重機(jī)制function UserList() { const [users, setUsers] useState([]) useEffect(() { fetch(/api/users) .then(r r.json()) .then(setUsers) }, []) }這種寫法的問題在于fetch是一次性的——組件掛載時(shí)執(zhí)行一次結(jié)果只寫入本地useState。當(dāng)UserList在頁面上出現(xiàn)兩次例如同時(shí)存在于側(cè)邊欄與主內(nèi)容區(qū)兩個(gè)實(shí)例各自請(qǐng)求/api/users產(chǎn)生兩份重復(fù)請(qǐng)求同時(shí)沒有任何緩存層組件卸載再掛載、路由切換返回時(shí)都會(huì)再次請(qǐng)求。三、正確模式useSWR 讓多個(gè)實(shí)例共享同一請(qǐng)求SWRStale-While-Revalidate的核心價(jià)值在于它把請(qǐng)求的結(jié)果提升為全局共享的緩存層而不是組件私有的 state。相同 key 的請(qǐng)求在去重窗口內(nèi)只發(fā)出一次所有訂閱該 key 的組件實(shí)例共享同一份數(shù)據(jù)和緩存。規(guī)則文檔給出的標(biāo)準(zhǔn)寫法import useSWR from swr function UserList() { const { data: users } useSWR(/api/users, fetcher) }其中/api/users是緩存 keySWR 也支持?jǐn)?shù)組形式的 keyfetcher是接收 key 并返回 Promise 的請(qǐng)求函數(shù)。SWR 會(huì)保證去重deduplication同一時(shí)間窗口內(nèi)相同 key 的并發(fā)請(qǐng)求只觸發(fā)一次網(wǎng)絡(luò)請(qǐng)求緩存caching請(qǐng)求結(jié)果緩存于全局緩存池組件重掛載時(shí)先返回緩存數(shù)據(jù)重新驗(yàn)證revalidation在組件聚焦、網(wǎng)絡(luò)重連等時(shí)機(jī)自動(dòng)后臺(tái)重新拉取并更新緩存讓界面數(shù)據(jù)保持新鮮。在 Papermark 中SWR 依賴版本為^2.4.1見 package.jsonfetcher 統(tǒng)一封裝在 lib/utils 中導(dǎo)出所有數(shù)據(jù) hooks 共用同一套請(qǐng)求函數(shù)例如 use-document.ts 中的const { data: document, error, mutate } useSWRDocumentWithVersion( teamInfo?.currentTeam?.id id /api/teams/${teamInfo?.currentTeam?.id}/documents/${encodeURIComponent(id)}, fetcher, { /* 詳見下文配置小節(jié) */ }, );可以看到key 是由團(tuán)隊(duì) ID 與文檔 ID 拼接而成的完整 API 路徑天然具備按資源隔離緩存的能力。四、進(jìn)階用法一不可變數(shù)據(jù)與 useSWRImmutable對(duì)于配置、用戶代理信息、預(yù)覽元數(shù)據(jù)這類幾乎不會(huì)變化的數(shù)據(jù)頻繁重新驗(yàn)證毫無意義反而徒增 API 請(qǐng)求。規(guī)則文檔提示使用不可變模式import { useImmutableSWR } from /lib/swr function StaticContent() { const { data } useImmutableSWR(/api/config, fetcher) }在 Papermark 倉庫中實(shí)際落地用的是 SWR 官方導(dǎo)出的useSWRImmutable來自swr/immutable效果等價(jià)——禁用所有自動(dòng)重新驗(yàn)證數(shù)據(jù)僅在首次請(qǐng)求時(shí)獲取。倉庫中多處使用這一模式例如 use-document-preview.tsconst { data: document, error, mutate, } useSWRImmutableDocumentPreviewData( isOpen currentTeamId documentId ? /api/teams/${currentTeamId}/documents/${documentId}/preview-data : null, fetcher, { dedupingInterval: 10000, revalidateOnFocus: false, revalidateOnReconnect: false, }, );這個(gè)例子同時(shí)示范了兩個(gè)關(guān)鍵實(shí)踐條件 keyconditional key當(dāng)isOpen、currentTeamId或documentId任一為假時(shí)key 傳nullSWR 不會(huì)發(fā)起請(qǐng)求。這解決了彈窗未打開時(shí)也預(yù)取數(shù)據(jù)的浪費(fèi)問題是 SWR 官方推薦的按需請(qǐng)求手法顯式關(guān)閉聚焦/重連重新驗(yàn)證預(yù)覽數(shù)據(jù)以打開彈窗時(shí)獲取的版本為準(zhǔn)避免用戶切回標(biāo)簽頁時(shí)數(shù)據(jù)被意外刷新。類似的不可變用法還出現(xiàn)在數(shù)據(jù)室訪客 UA 信息的獲取中use-dataroom-stats.ts 用useSWRImmutable拉取訪客的設(shè)備、瀏覽器、城市與操作系統(tǒng)信息——這類信息在一次會(huì)話內(nèi)恒定不變非常適合 immutable 模式。五、進(jìn)階用法二變更操作與 useSWRMutation去重解決的是讀的問題而寫操作同樣需要規(guī)范。規(guī)則文檔給出的變更寫法import { useSWRMutation } from swr/mutation function UpdateButton() { const { trigger } useSWRMutation(/api/user, updateUser) return button onClick{() trigger()}Update/button }useSWRMutation的特點(diǎn)是請(qǐng)求只在trigger()被調(diào)用時(shí)才發(fā)起不會(huì)在組件掛載時(shí)自動(dòng)執(zhí)行它天然兼容 SWR 的緩存體系變更完成后可以配合mutate觸發(fā)相關(guān) key 的重新驗(yàn)證實(shí)現(xiàn)寫后刷新的閉環(huán)。相比在useEffect中手動(dòng)調(diào)用fetch再自己管理 loading/error 狀態(tài)這種模式顯著減少了樣板代碼也避免了寫操作被重復(fù)觸發(fā)的隱患。六、dedupingInterval 與重新驗(yàn)證策略的工程化配置SWR 的自動(dòng)去重并非無限期生效而是受dedupingInterval去重窗口單位毫秒約束窗口內(nèi)相同 key 的請(qǐng)求被合并為一次窗口過期后才會(huì)允許再次請(qǐng)求。Papermark 的各個(gè)數(shù)據(jù) hooks 針對(duì)不同數(shù)據(jù)特性配置了差異化的去重與重新驗(yàn)證策略可直接作為調(diào)參參考場(chǎng)景配置倉庫示例設(shè)計(jì)意圖普通統(tǒng)計(jì)數(shù)據(jù)文檔/數(shù)據(jù)室視圖dedupingInterval: 10000use-dataroom-stats.ts、use-stats.ts10 秒內(nèi)合并重復(fù)請(qǐng)求兼顧統(tǒng)計(jì)近實(shí)時(shí)性文檔詳情與鏈接列表dedupingInterval: 30000、revalidateOnFocus: false、revalidateOnReconnect: false、revalidateIfStale: falseuse-document.ts30 秒窗口文檔詳情變更不頻繁減少后臺(tái)刷新造成的 API 流量訪客分頁列表dedupingInterval: 20000use-document.ts分頁數(shù)據(jù) 20 秒窗口翻頁時(shí)避免重復(fù)請(qǐng)求文檔處理進(jìn)度輪詢r(jià)efreshInterval: 3000use-document.tsPDF 上傳后需要持續(xù)跟蹤處理進(jìn)度用 3 秒輪詢替代手動(dòng)定時(shí)器縮略圖dedupingInterval: 1200000、revalidateOnFocus: false、revalidateIfStale: false、refreshInterval: 0use-document.ts縮略圖 20 分鐘1200000ms去重窗口幾乎視為不可變數(shù)據(jù)預(yù)覽數(shù)據(jù) / UA 信息 / 簽約狀態(tài)immutable不自動(dòng)重新驗(yàn)證use-document-preview.ts、agreement-section.tsx一次性或恒定數(shù)據(jù)只在顯式時(shí)機(jī)獲取其中 agreement-section.tsx 的注釋非常典型Only hydrate while unconfirmed (null key disables the request); useSWRImmutable since signed status is effectively one-shot.——簽約狀態(tài)在確認(rèn)后即為終態(tài)屬于一次性數(shù)據(jù)用 immutable 條件 key 組合實(shí)現(xiàn)未確認(rèn)不請(qǐng)求、確認(rèn)后只請(qǐng)求一次。從這些示例可以總結(jié)出調(diào)參原則數(shù)據(jù)變化越頻繁dedupingInterval越短或配合refreshInterval主動(dòng)輪詢?nèi)缣幚磉M(jìn)度 3 秒一刷數(shù)據(jù)變化越罕見窗口越長(zhǎng)甚至直接使用 immutable 模式徹底禁用自動(dòng)刷新如縮略圖 20 分鐘revalidateOnFocus: false/revalidateOnReconnect: false適用于對(duì)焦點(diǎn)回切刷新不敏感的頁面可顯著降低后臺(tái) API 流量條件 key傳null是所有場(chǎng)景都值得采用的默認(rèn)習(xí)慣用于阻止未就緒或未打開的組件浪費(fèi)請(qǐng)求。七、Papermark 中的規(guī)模化實(shí)踐lib/swr 目錄去重規(guī)則的價(jià)值在 Papermark 中體現(xiàn)為體系化的數(shù)據(jù)層倉庫在 lib/swr 目錄下集中維護(hù)了 40 余個(gè)數(shù)據(jù) hooks覆蓋文檔、數(shù)據(jù)室、訪客、團(tuán)隊(duì)、計(jì)費(fèi)、域名、標(biāo)簽、權(quán)限組等全部領(lǐng)域每個(gè) hook 都以u(píng)seXxx命名并統(tǒng)一返回{ data, loading, error, mutate }形狀。從源碼結(jié)構(gòu)看這套目錄的設(shè)計(jì)思路是統(tǒng)一 fetcher所有 hooks 從 lib/utils 引入同一個(gè)fetcher保證請(qǐng)求行為一致統(tǒng)一緩存 key 規(guī)則key 一律由teamId 資源 ID API 路徑拼接而成例如/api/teams/${teamId}/documents/${id}/stats同一資源在所有頁面共享同一份緩存hook 內(nèi)封裝去重策略每個(gè) hook 內(nèi)部針對(duì)自己數(shù)據(jù)的特點(diǎn)配置dedupingInterval與重新驗(yàn)證選項(xiàng)業(yè)務(wù)組件無需關(guān)心去重細(xì)節(jié)直接消費(fèi) hook 返回值與上下文聯(lián)動(dòng)hooks 大量依賴 team-context 提供的currentTeamId團(tuán)隊(duì)切換時(shí) key 自然變化緩存自動(dòng)按團(tuán)隊(duì)隔離。這種數(shù)據(jù) hooks 集中管理的模式讓 SWR 的去重、緩存與重新驗(yàn)證能力貫穿整個(gè)客戶端無論是useDocument文檔詳情、useDataroomStats數(shù)據(jù)室統(tǒng)計(jì)還是useVisitorUserAgent訪客設(shè)備信息都只需關(guān)心數(shù)據(jù)與 key網(wǎng)絡(luò)層的去重由 SWR 統(tǒng)一完成。團(tuán)隊(duì)切換、路由跳轉(zhuǎn)、組件卸載重掛載都不會(huì)產(chǎn)生重復(fù)請(qǐng)求風(fēng)暴。八、最佳實(shí)踐清單結(jié)合規(guī)則文檔與 Papermark 源碼可將客戶端數(shù)據(jù)請(qǐng)求去重總結(jié)為以下可執(zhí)行清單用useSWR替代useState useEffect fetch讓相同 key 的請(qǐng)求在去重窗口內(nèi)只發(fā)出一次key 使用完整的、可唯一標(biāo)識(shí)資源的 API 路徑如teamId documentId拼接保證緩存粒度正確對(duì)幾乎不變的數(shù)據(jù)使用 immutable 模式swr/immutable的useSWRImmutable顯式關(guān)閉自動(dòng)重新驗(yàn)證對(duì)寫操作使用useSWRMutation僅在trigger()時(shí)發(fā)起請(qǐng)求并配合mutate做寫后刷新按數(shù)據(jù)特性配置dedupingInterval頻繁變化的數(shù)據(jù)用短窗口或refreshInterval輪詢罕見變化的數(shù)據(jù)用長(zhǎng)窗口或 immutable利用條件 keynull按需請(qǐng)求未就緒、未打開、未確認(rèn)的場(chǎng)景一律不發(fā)請(qǐng)求在后臺(tái)類頁面顯式關(guān)閉revalidateOnFocus與revalidateOnReconnect削減不必要的后臺(tái)流量。這套模式的最終效果正如規(guī)則文檔所總結(jié)SWR 讓請(qǐng)求去重、緩存與重新驗(yàn)證在組件實(shí)例之間自動(dòng)生效——寫更少的請(qǐng)求代碼獲得更穩(wěn)的緩存一致性與更低的后端負(fù)載。贊分享后端前端企業(yè)應(yīng)用【免費(fèi)下載鏈接】papermarkPapermark is the open-source DocSend alternative and secure data rooms with built-in analytics and custom domains.項(xiàng)目地址https://gitcode.com/GitHub_Trending/pa/papermark點(diǎn)擊查看免費(fèi)下載相關(guān)推薦Mediago 前端數(shù)據(jù)請(qǐng)求去重實(shí)踐用 SWR 統(tǒng)一緩存、去重與再驗(yàn)證Mediago 前端數(shù)據(jù)請(qǐng)求去重實(shí)踐用 SWR 統(tǒng)一緩存、去重與再驗(yàn)證 導(dǎo)讀 本文圍繞 Mediago 開源項(xiàng)目中前端 apps/ui 的一條核心工程規(guī)范音視頻桌面應(yīng)用后端Phoenix 前端數(shù)據(jù)請(qǐng)求去重實(shí)踐用 SWR 實(shí)現(xiàn)自動(dòng)去重、緩存與重新驗(yàn)證Phoenix 前端數(shù)據(jù)請(qǐng)求去重實(shí)踐用 SWR 實(shí)現(xiàn)自動(dòng)去重、緩存與重新驗(yàn)證 導(dǎo)讀 在 PhoenixAI Observability Evaluati可觀測(cè)性AI 評(píng)測(cè)LLMOpsAI 應(yīng)用人工智能Cherry Studio 客戶端請(qǐng)求去重實(shí)踐基于 SWR 的自動(dòng)去重、緩存與重新驗(yàn)證指南Cherry Studio 客戶端請(qǐng)求去重實(shí)踐基于 SWR 的自動(dòng)去重、緩存與重新驗(yàn)證指南 導(dǎo)讀 本文圍繞 Vercel React 最佳實(shí)踐規(guī)則集中的 clAI 應(yīng)用大模型桌面應(yīng)用本地部署RAG上一篇Qwen Code Web Shell 工作區(qū)總覽側(cè)邊欄工作區(qū)健康度、Facet 芯片與 Workspace 菜單設(shè)計(jì)解析下一篇Mojo 可變參數(shù)Variadics完整指南從參數(shù)列表、VariadicList 到 VariadicPack 與關(guān)鍵字參數(shù)創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Papermark 客戶端數(shù)據(jù)請(qǐng)求去重實(shí)踐：用 SWR 統(tǒng)一緩存、去重與重新驗(yàn)證
后端前端企業(yè)應(yīng)用【免費(fèi)下載鏈接】papermarkPapermark is the open-source DocSend alternative and secure data rooms with built-in analytics and custom domains.項(xiàng)目地址https://gitcode.com/GitHub_Trending/pa/papermark點(diǎn)擊查看免費(fèi)下載導(dǎo)讀本文圍繞 Papermark 項(xiàng)目中前端數(shù)據(jù)請(qǐng)求的最佳實(shí)踐規(guī)則展開講解如何在 React 應(yīng)用中通過 SWR 實(shí)現(xiàn)跨組件實(shí)例的請(qǐng)求自動(dòng)去重deduplication、緩存與重新驗(yàn)證revalidation避免多個(gè)組件同時(shí)掛載時(shí)對(duì)同一 API 接口發(fā)起重復(fù)請(qǐng)求。讀完本文你將掌握從useState useEffect fetch到useSWR的改造方法理解不可變數(shù)據(jù)與變更操作的兩種進(jìn)階用法并了解 Papermark 在 lib/swr 目錄下 40 余個(gè)數(shù)據(jù) hooks 中如何配置dedupingInterval、條件 key 與輪詢刷新直接指導(dǎo)你在真實(shí)項(xiàng)目中落地這套模式。一、問題背景為什么客戶端請(qǐng)求需要去重在 React 應(yīng)用中同一個(gè)數(shù)據(jù)源經(jīng)常被多個(gè)組件實(shí)例消費(fèi)。典型場(chǎng)景包括文檔列表頁同時(shí)渲染多個(gè)卡片組件、分析面板中多個(gè)圖表組件讀取同一份統(tǒng)計(jì)數(shù)據(jù)、數(shù)據(jù)室Dataroom詳情頁中多個(gè)區(qū)塊都需要文檔訪問記錄。如果每個(gè)組件都在useEffect中獨(dú)立發(fā)起fetch請(qǐng)求則 N 個(gè)組件實(shí)例會(huì)向服務(wù)器發(fā)出 N 份完全相同的請(qǐng)求造成重復(fù)網(wǎng)絡(luò)流量同一份數(shù)據(jù)被反復(fù)拉取浪費(fèi)帶寬API 負(fù)載放大后端接口被無意義地打滿尤其在儀表盤類頁面格外明顯數(shù)據(jù)不一致風(fēng)險(xiǎn)各實(shí)例各自維護(hù)一份狀態(tài)刷新時(shí)機(jī)不同步時(shí)界面會(huì)出現(xiàn)短暫差異。Papermark 的這條規(guī)則見 client-swr-dedup.md將其影響等級(jí)標(biāo)為 MEDIUM-HIGH正是因?yàn)樗苯雨P(guān)系到客戶端性能與后端 API 穩(wěn)定性。二、反模式useState useEffect fetch 各自拉取規(guī)則文檔首先給出了需要避免的寫法——每個(gè)組件實(shí)例獨(dú)立發(fā)起請(qǐng)求無任何去重機(jī)制function UserList() { const [users, setUsers] useState([]) useEffect(() { fetch(/api/users) .then(r r.json()) .then(setUsers) }, []) }這種寫法的問題在于fetch是一次性的——組件掛載時(shí)執(zhí)行一次結(jié)果只寫入本地useState。當(dāng)UserList在頁面上出現(xiàn)兩次例如同時(shí)存在于側(cè)邊欄與主內(nèi)容區(qū)兩個(gè)實(shí)例各自請(qǐng)求/api/users產(chǎn)生兩份重復(fù)請(qǐng)求同時(shí)沒有任何緩存層組件卸載再掛載、路由切換返回時(shí)都會(huì)再次請(qǐng)求。三、正確模式useSWR 讓多個(gè)實(shí)例共享同一請(qǐng)求SWRStale-While-Revalidate的核心價(jià)值在于它把請(qǐng)求的結(jié)果提升為全局共享的緩存層而不是組件私有的 state。相同 key 的請(qǐng)求在去重窗口內(nèi)只發(fā)出一次所有訂閱該 key 的組件實(shí)例共享同一份數(shù)據(jù)和緩存。規(guī)則文檔給出的標(biāo)準(zhǔn)寫法import useSWR from swr function UserList() { const { data: users } useSWR(/api/users, fetcher) }其中/api/users是緩存 keySWR 也支持?jǐn)?shù)組形式的 keyfetcher是接收 key 并返回 Promise 的請(qǐng)求函數(shù)。SWR 會(huì)保證去重deduplication同一時(shí)間窗口內(nèi)相同 key 的并發(fā)請(qǐng)求只觸發(fā)一次網(wǎng)絡(luò)請(qǐng)求緩存caching請(qǐng)求結(jié)果緩存于全局緩存池組件重掛載時(shí)先返回緩存數(shù)據(jù)重新驗(yàn)證revalidation在組件聚焦、網(wǎng)絡(luò)重連等時(shí)機(jī)自動(dòng)后臺(tái)重新拉取并更新緩存讓界面數(shù)據(jù)保持新鮮。在 Papermark 中SWR 依賴版本為^2.4.1見 package.jsonfetcher 統(tǒng)一封裝在 lib/utils 中導(dǎo)出所有數(shù)據(jù) hooks 共用同一套請(qǐng)求函數(shù)例如 use-document.ts 中的const { data: document, error, mutate } useSWRDocumentWithVersion( teamInfo?.currentTeam?.id id /api/teams/${teamInfo?.currentTeam?.id}/documents/${encodeURIComponent(id)}, fetcher, { /* 詳見下文配置小節(jié) */ }, );可以看到key 是由團(tuán)隊(duì) ID 與文檔 ID 拼接而成的完整 API 路徑天然具備按資源隔離緩存的能力。四、進(jìn)階用法一不可變數(shù)據(jù)與 useSWRImmutable對(duì)于配置、用戶代理信息、預(yù)覽元數(shù)據(jù)這類幾乎不會(huì)變化的數(shù)據(jù)頻繁重新驗(yàn)證毫無意義反而徒增 API 請(qǐng)求。規(guī)則文檔提示使用不可變模式import { useImmutableSWR } from /lib/swr function StaticContent() { const { data } useImmutableSWR(/api/config, fetcher) }在 Papermark 倉庫中實(shí)際落地用的是 SWR 官方導(dǎo)出的useSWRImmutable來自swr/immutable效果等價(jià)——禁用所有自動(dòng)重新驗(yàn)證數(shù)據(jù)僅在首次請(qǐng)求時(shí)獲取。倉庫中多處使用這一模式例如 use-document-preview.tsconst { data: document, error, mutate, } useSWRImmutableDocumentPreviewData( isOpen currentTeamId documentId ? /api/teams/${currentTeamId}/documents/${documentId}/preview-data : null, fetcher, { dedupingInterval: 10000, revalidateOnFocus: false, revalidateOnReconnect: false, }, );這個(gè)例子同時(shí)示范了兩個(gè)關(guān)鍵實(shí)踐條件 keyconditional key當(dāng)isOpen、currentTeamId或documentId任一為假時(shí)key 傳nullSWR 不會(huì)發(fā)起請(qǐng)求。這解決了彈窗未打開時(shí)也預(yù)取數(shù)據(jù)的浪費(fèi)問題是 SWR 官方推薦的按需請(qǐng)求手法顯式關(guān)閉聚焦/重連重新驗(yàn)證預(yù)覽數(shù)據(jù)以打開彈窗時(shí)獲取的版本為準(zhǔn)避免用戶切回標(biāo)簽頁時(shí)數(shù)據(jù)被意外刷新。類似的不可變用法還出現(xiàn)在數(shù)據(jù)室訪客 UA 信息的獲取中use-dataroom-stats.ts 用useSWRImmutable拉取訪客的設(shè)備、瀏覽器、城市與操作系統(tǒng)信息——這類信息在一次會(huì)話內(nèi)恒定不變非常適合 immutable 模式。五、進(jìn)階用法二變更操作與 useSWRMutation去重解決的是讀的問題而寫操作同樣需要規(guī)范。規(guī)則文檔給出的變更寫法import { useSWRMutation } from swr/mutation function UpdateButton() { const { trigger } useSWRMutation(/api/user, updateUser) return button onClick{() trigger()}Update/button }useSWRMutation的特點(diǎn)是請(qǐng)求只在trigger()被調(diào)用時(shí)才發(fā)起不會(huì)在組件掛載時(shí)自動(dòng)執(zhí)行它天然兼容 SWR 的緩存體系變更完成后可以配合mutate觸發(fā)相關(guān) key 的重新驗(yàn)證實(shí)現(xiàn)寫后刷新的閉環(huán)。相比在useEffect中手動(dòng)調(diào)用fetch再自己管理 loading/error 狀態(tài)這種模式顯著減少了樣板代碼也避免了寫操作被重復(fù)觸發(fā)的隱患。六、dedupingInterval 與重新驗(yàn)證策略的工程化配置SWR 的自動(dòng)去重并非無限期生效而是受dedupingInterval去重窗口單位毫秒約束窗口內(nèi)相同 key 的請(qǐng)求被合并為一次窗口過期后才會(huì)允許再次請(qǐng)求。Papermark 的各個(gè)數(shù)據(jù) hooks 針對(duì)不同數(shù)據(jù)特性配置了差異化的去重與重新驗(yàn)證策略可直接作為調(diào)參參考場(chǎng)景配置倉庫示例設(shè)計(jì)意圖普通統(tǒng)計(jì)數(shù)據(jù)文檔/數(shù)據(jù)室視圖dedupingInterval: 10000use-dataroom-stats.ts、use-stats.ts10 秒內(nèi)合并重復(fù)請(qǐng)求兼顧統(tǒng)計(jì)近實(shí)時(shí)性文檔詳情與鏈接列表dedupingInterval: 30000、revalidateOnFocus: false、revalidateOnReconnect: false、revalidateIfStale: falseuse-document.ts30 秒窗口文檔詳情變更不頻繁減少后臺(tái)刷新造成的 API 流量訪客分頁列表dedupingInterval: 20000use-document.ts分頁數(shù)據(jù) 20 秒窗口翻頁時(shí)避免重復(fù)請(qǐng)求文檔處理進(jìn)度輪詢r(jià)efreshInterval: 3000use-document.tsPDF 上傳后需要持續(xù)跟蹤處理進(jìn)度用 3 秒輪詢替代手動(dòng)定時(shí)器縮略圖dedupingInterval: 1200000、revalidateOnFocus: false、revalidateIfStale: false、refreshInterval: 0use-document.ts縮略圖 20 分鐘1200000ms去重窗口幾乎視為不可變數(shù)據(jù)預(yù)覽數(shù)據(jù) / UA 信息 / 簽約狀態(tài)immutable不自動(dòng)重新驗(yàn)證use-document-preview.ts、agreement-section.tsx一次性或恒定數(shù)據(jù)只在顯式時(shí)機(jī)獲取其中 agreement-section.tsx 的注釋非常典型Only hydrate while unconfirmed (null key disables the request); useSWRImmutable since signed status is effectively one-shot.——簽約狀態(tài)在確認(rèn)后即為終態(tài)屬于一次性數(shù)據(jù)用 immutable 條件 key 組合實(shí)現(xiàn)未確認(rèn)不請(qǐng)求、確認(rèn)后只請(qǐng)求一次。從這些示例可以總結(jié)出調(diào)參原則數(shù)據(jù)變化越頻繁dedupingInterval越短或配合refreshInterval主動(dòng)輪詢?nèi)缣幚磉M(jìn)度 3 秒一刷數(shù)據(jù)變化越罕見窗口越長(zhǎng)甚至直接使用 immutable 模式徹底禁用自動(dòng)刷新如縮略圖 20 分鐘revalidateOnFocus: false/revalidateOnReconnect: false適用于對(duì)焦點(diǎn)回切刷新不敏感的頁面可顯著降低后臺(tái) API 流量條件 key傳null是所有場(chǎng)景都值得采用的默認(rèn)習(xí)慣用于阻止未就緒或未打開的組件浪費(fèi)請(qǐng)求。七、Papermark 中的規(guī)模化實(shí)踐lib/swr 目錄去重規(guī)則的價(jià)值在 Papermark 中體現(xiàn)為體系化的數(shù)據(jù)層倉庫在 lib/swr 目錄下集中維護(hù)了 40 余個(gè)數(shù)據(jù) hooks覆蓋文檔、數(shù)據(jù)室、訪客、團(tuán)隊(duì)、計(jì)費(fèi)、域名、標(biāo)簽、權(quán)限組等全部領(lǐng)域每個(gè) hook 都以u(píng)seXxx命名并統(tǒng)一返回{ data, loading, error, mutate }形狀。從源碼結(jié)構(gòu)看這套目錄的設(shè)計(jì)思路是統(tǒng)一 fetcher所有 hooks 從 lib/utils 引入同一個(gè)fetcher保證請(qǐng)求行為一致統(tǒng)一緩存 key 規(guī)則key 一律由teamId 資源 ID API 路徑拼接而成例如/api/teams/${teamId}/documents/${id}/stats同一資源在所有頁面共享同一份緩存hook 內(nèi)封裝去重策略每個(gè) hook 內(nèi)部針對(duì)自己數(shù)據(jù)的特點(diǎn)配置dedupingInterval與重新驗(yàn)證選項(xiàng)業(yè)務(wù)組件無需關(guān)心去重細(xì)節(jié)直接消費(fèi) hook 返回值與上下文聯(lián)動(dòng)hooks 大量依賴 team-context 提供的currentTeamId團(tuán)隊(duì)切換時(shí) key 自然變化緩存自動(dòng)按團(tuán)隊(duì)隔離。這種數(shù)據(jù) hooks 集中管理的模式讓 SWR 的去重、緩存與重新驗(yàn)證能力貫穿整個(gè)客戶端無論是useDocument文檔詳情、useDataroomStats數(shù)據(jù)室統(tǒng)計(jì)還是useVisitorUserAgent訪客設(shè)備信息都只需關(guān)心數(shù)據(jù)與 key網(wǎng)絡(luò)層的去重由 SWR 統(tǒng)一完成。團(tuán)隊(duì)切換、路由跳轉(zhuǎn)、組件卸載重掛載都不會(huì)產(chǎn)生重復(fù)請(qǐng)求風(fēng)暴。八、最佳實(shí)踐清單結(jié)合規(guī)則文檔與 Papermark 源碼可將客戶端數(shù)據(jù)請(qǐng)求去重總結(jié)為以下可執(zhí)行清單用useSWR替代useState useEffect fetch讓相同 key 的請(qǐng)求在去重窗口內(nèi)只發(fā)出一次key 使用完整的、可唯一標(biāo)識(shí)資源的 API 路徑如teamId documentId拼接保證緩存粒度正確對(duì)幾乎不變的數(shù)據(jù)使用 immutable 模式swr/immutable的useSWRImmutable顯式關(guān)閉自動(dòng)重新驗(yàn)證對(duì)寫操作使用useSWRMutation僅在trigger()時(shí)發(fā)起請(qǐng)求并配合mutate做寫后刷新按數(shù)據(jù)特性配置dedupingInterval頻繁變化的數(shù)據(jù)用短窗口或refreshInterval輪詢罕見變化的數(shù)據(jù)用長(zhǎng)窗口或 immutable利用條件 keynull按需請(qǐng)求未就緒、未打開、未確認(rèn)的場(chǎng)景一律不發(fā)請(qǐng)求在后臺(tái)類頁面顯式關(guān)閉revalidateOnFocus與revalidateOnReconnect削減不必要的后臺(tái)流量。這套模式的最終效果正如規(guī)則文檔所總結(jié)SWR 讓請(qǐng)求去重、緩存與重新驗(yàn)證在組件實(shí)例之間自動(dòng)生效——寫更少的請(qǐng)求代碼獲得更穩(wěn)的緩存一致性與更低的后端負(fù)載。贊分享后端前端企業(yè)應(yīng)用【免費(fèi)下載鏈接】papermarkPapermark is the open-source DocSend alternative and secure data rooms with built-in analytics and custom domains.項(xiàng)目地址https://gitcode.com/GitHub_Trending/pa/papermark點(diǎn)擊查看免費(fèi)下載相關(guān)推薦Mediago 前端數(shù)據(jù)請(qǐng)求去重實(shí)踐用 SWR 統(tǒng)一緩存、去重與再驗(yàn)證Mediago 前端數(shù)據(jù)請(qǐng)求去重實(shí)踐用 SWR 統(tǒng)一緩存、去重與再驗(yàn)證 導(dǎo)讀 本文圍繞 Mediago 開源項(xiàng)目中前端 apps/ui 的一條核心工程規(guī)范音視頻桌面應(yīng)用后端Phoenix 前端數(shù)據(jù)請(qǐng)求去重實(shí)踐用 SWR 實(shí)現(xiàn)自動(dòng)去重、緩存與重新驗(yàn)證Phoenix 前端數(shù)據(jù)請(qǐng)求去重實(shí)踐用 SWR 實(shí)現(xiàn)自動(dòng)去重、緩存與重新驗(yàn)證 導(dǎo)讀 在 PhoenixAI Observability Evaluati可觀測(cè)性AI 評(píng)測(cè)LLMOpsAI 應(yīng)用人工智能Cherry Studio 客戶端請(qǐng)求去重實(shí)踐基于 SWR 的自動(dòng)去重、緩存與重新驗(yàn)證指南Cherry Studio 客戶端請(qǐng)求去重實(shí)踐基于 SWR 的自動(dòng)去重、緩存與重新驗(yàn)證指南 導(dǎo)讀 本文圍繞 Vercel React 最佳實(shí)踐規(guī)則集中的 clAI 應(yīng)用大模型桌面應(yīng)用本地部署RAG上一篇Qwen Code Web Shell 工作區(qū)總覽側(cè)邊欄工作區(qū)健康度、Facet 芯片與 Workspace 菜單設(shè)計(jì)解析下一篇Mojo 可變參數(shù)Variadics完整指南從參數(shù)列表、VariadicList 到 VariadicPack 與關(guān)鍵字參數(shù)創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考