Cache mutation for extended swr features like swr infinite / subscription

[huozhi]

For now the cache for basic keys of useSWR hook can be manipulated by the mutate() API with the filtering key. We need to find a way to manipulate it from API level.

x-ref: #2281

[Itttz]

Update?

[Lexizz7]

You can test my workaround in https://github.com/vercel/swr/issues/1670#issuecomment-1625977770

[kristojorg]

This is causing a relatively large problem for our application: we are unable to fully clear the SWR cache on sign in / sign out using the unbound mutate function. This quickly leads to invalid states, for example a user visits a page A and gets redirected to sign in. After sign in, they can never get back to page A because useSWRInfinite has cached the 401 error and it cannot be cleared by mutate(() => true, undefined) or mutate(() => true, undefined, true).

For the time being the only solution is to call useSWRInfinite for page A (and any other useSWRInfinite the app uses) in the sign in page and call the bound mutate() function after they sign in.

tl;dr: there is no good way to reset/invalidate the SWR cache when using useSWRInfinite

[jackirvine97]

Echo the above point from @kristojorg, there is no clean mechanism for fully clearing the cache in applications which leverage infinite systems (as also discussed here: https://github.com/vercel/swr/issues/2281)

This is a critical usage pattern for applications with sign-in/out functionality

[karol-wons-deel]

I am upvoting this feature request. We need a mechanism to clear useSWRInfinite keys with the global mutate function

  const { mutate } = useSWRConfig();

We've tried every suggested idea, but to no avail. The closes we got is https://github.com/vercel/swr/issues/1670#issuecomment-1757558376 but we faced the same issue.