Last 12 weeks · 16 commits
4 of 6 standards met
Description This PR aligns the behavior of with regarding conditional fetching. Previously, providing a key (or a function returning a falsy value) to caused an internal during serialization and threw a "missing key" error when calling . This behavior contradicted the SWR documentation on conditional fetching, which states that falsy keys should simply prevent the request. Changes Logic Fix: Added a guard clause in the function to return early if the resolved key is falsy. This ensures consistency across the library and prevents unhandled console errors. Test Update: Updated the legacy test case to reflect the correct documented behavior (it now expects a silent return instead of an error throw). Bug Fix:** Prevented the internal utility from being called with invalid keys, eliminating the reported console noise. Linked Issue Fixes #4217 Testing Verified with a new regression test for keys. Ran the full mutation test suite: . All tests passed. Cc: @SL-YutoTakagi
Repository: vercel/swr. Description: React Hooks for Data Fetching Stars: 32327, Forks: 1319. Primary language: TypeScript. Languages: TypeScript (98.8%), JavaScript (1.2%). License: MIT. Homepage: https://swr.vercel.app Topics: cache, data, data-fetching, fetch, hook, hooks, nextjs, react, react-native, stale-while-revalidate, suspense, swr, vercel. Latest release: v2.4.0 (3w ago). Open PRs: 43, open issues: 142. Last activity: 1d ago. Community health: 100%. Top contributors: shuding, huozhi, promer94, koba04, vercel-release-bot, dependabot[bot], sergiodxa, cryptiklemur, matamatanot, anothertempore and others.
TypeScript
Description / Observed Behavior The documentation states that 's parameter is "same as mutate's key" which references "same as useSWR's key". However, unlike , does not accept as a key value and throws a console error when a falsy value is passed. This is related to the unresolved #2456 where filter functions also don't work despite the documentation suggesting they should. Documentation chain: 1. useSWR API docs explicitly allow : https://swr.vercel.app/docs/api key: a unique key string for the request (or a function / array / null) 2. useSWRMutation docs state: https://swr.vercel.app/docs/mutation key: same as mutate's key 3. mutate docs reference: key: same as useSWR's key. but the function will behave as a filter function This documentation chain implies should be acceptable for , but it is not. Expected Behavior Based on the documentation and consistency with , I expected the following pattern to work without errors: This pattern is commonly used with for conditional fetching as documented here: https://swr.vercel.app/docs/conditional-fetching Repro Steps / Code Example Console error: The error comes from the function which is called in the mutation implementation but not properly handled for falsy values. Root cause: useSWRMutation calls : https://github.com/vercel/swr/blob/main/src/mutation/index.ts The function logs an error for falsy values: https://github.com/vercel/swr/blob/main/src/_internal/utils/serialize.ts#L6 In contrast, useSWR handles falsy keys properly: https://github.com/vercel/swr/blob/main/src/index/use-swr.ts#L213 Additional Context SWR version: Latest (as of February 2026)
Bug report Description / Observed Behavior When using , the hook should disable revalidation on focus. However, if you leave the app window and go back in (triggering a window focus event), the fetcher function is called again. This is confirmed by the inside the fetcher firing every time the app regains focus. Expected Behavior should implicitly set , , and to false. Leaving the app and returning should not trigger the fetcher function if the cache is already populated and the SWR key has not changed. Repro Steps / Code Example Link to reproduction: CodeSandbox. Look inside the console! Don’t switch focus too quickly; otherwise, you won’t see it due to the deduping interval in SWR. Additional Context SWR version: React version:
Bug report Description / Observed Behavior When updating to version 2.4.0 we noticed updating the cache with the revalidate option set to false causes to be stuck true. Expected Behavior Expected it to behave as it does in 2.3.8 where updating the cache works and does not result in a stuck loading state. Repro Steps / Code Example In version 2.4.0 https://stackblitz.com/edit/vitejs-vite-j44f8kf9?file=src%2FApp.jsx In version 2.3.8 https://stackblitz.com/edit/vitejs-vite-k9t9rvsg?file=src%2FApp.jsx Additional Context SWR version. 2.4.0
The reported issue claims that calling with causes to remain stuck on in version 2.4.0. Investigation Results Created comprehensive test cases covering multiple scenarios where this bug could manifest: Mutating cache on hooks without fetchers Mutating cache during ongoing fetches Mutating cache before component mount Mutating cache after initial data load All test scenarios pass without code modifications. The existing implementation correctly handles loading states: 1. When a fetch is in progress and is called, the ongoing fetch completes normally 2. The mutation timestamp check properly discards stale fetch results and calls to reset and to 3. The snapshot logic correctly determines initial loading states for newly mounted components Conclusion The bug cannot be reproduced in the current v2.4.0 codebase. Either: The issue was already fixed in a previous commit The reproduction requires a specific edge case not covered by these tests The issue may not exist as described Recommend closing as unable to reproduce or requesting more specific reproduction steps from the reporter. Original prompt This section details on the original issue you should resolve* isLoading stuck on true when updating cache with revalidate false # Bug report ## Description / Observed Behavior When updating to Version 2.4.0 we noticed updating the cache with the revalidate option set to false causes to be stuck true. ## Expected Behavior Expected it to behave as it does in 2.3.8 where updating the cache works and result in a stuck loading state. ## Repro Steps / Code Example In version 2.4.0 https://stackblitz.com/edit/vitejs-vite-j44f8kf9?file=src%2FApp.jsx In version 2.3.8 https://stackblitz.com/edit/vitejs-vite-k9t9rvsg?file=src%2FApp.jsx ## Additional Context SWR version. 2.4.0 ## Comments on the Issue (you are @copilot in this section) Fixes vercel/swr#4221 💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.