How should we handle partial revalidations?

[ephys]

Say you have a large list of items that has been paginated using useSWRPages

Currently, if we want to refresh the list, we have to call revalidate on every SWR which causes a lot of network traffic

In order to reduce traffic, APIs can typically provide filters to only retrieve elements that have been updated or created after a certain date, but I don't see a way to properly integrate that with SWR

My current solution is to have a second useSWR run next to my useSWRPages that polls that "recently updated data" endpoint, and to mutate the cache in the onSuccess of useSWR, but that feels hacky (it has to remove some data from some pages, add some data to other pages, etc)

I hope partial updates can become a first class citizen of the new pagination API given the high performance boost it would bring

Partial updates would also resolve this use-case

[sergiodxa]

Instead of using revalidate use mutate, there you can do:

import { mutate } from "swr";
mutate(key, currentData => /* update current data to add the new/updated item */. false);

You can also get mutate from useSWR instead of importing it, in that case the key is already set for you, you need to pass the function as first argument.

The false at the end prevents a revalidation to happen, if you don't pass it SWR will mutate the cached data and then request the whole data again to ensure it's correct, this is useful when doing optimistic UI, in your case you can disable it.

[ephys]

Thank you @sergiodxa, that's what I was doing but as I said it's awkward and complex, which is why I think it's important to keep this use case in mind when designing the new pagination API

In the end I had to bypass SWR completely for this use case for a number of reasons:

• We have to continuously re-render to update the "last update" timestamp that the SWR dedicated to polling uses
• mutating works fine if all you need to do is append to the first page of a useSWRPages (because that's the initial key), but if you need to update an element anywhere else in the list, or re-sort the list, it becomes a problem because SWR doesn't provide the list of keys used by a given useSWRPages
• The key changes every time a request is made (because the timestamp changes), so SWR caches the response under a new key every time even though it's never going to be used again. This data adds up quickly
• Even after hacking around and keeping track of my own list of keys, moving data around in the different pages is cumbersome

If interested, my final solution was to poll the endpoint manually in a useEffect hook and merge that response with useSWRPages.pagesSWR.data

If interested, this is what it looks like looks like this