Option to disable revalidating the first page when changing the size in useSWRInfinite

[dkryptr]

Bug report

Description / Observed Behavior

Running the infinite-scroll example on the latest release (1.0.0), I observe that the first page gets re-fetched on every call to setSize(size + 1)

Expected Behavior

setSize(size +1) should only fetch the next page.

Repro Steps / Code Example

1. Clone master
2. Add console.log(...args) to examples/infinite-scroll/libs/fetch.js
3. npm install && npm run dev
4. Inspect console logs as you scroll.

Additional Context

Changing the version of swr in the example back to 0.5.6 and updating the import of useSWRInfinite , this doesn't happen.

[shuding]

This is the expected behavior, we should have made it clear on the docs 🙏 . I’ll write to explain later.

[dkryptr]

So when fetching the next page, the expected behavior is to make two requests for the first and next page? Is there a way to disable this?

My concern is that if I implement 1.0.0, my infinite scrolling component is now sending double the requests for every user on the website.

[shuding]

@CGreenburg Yes. The reason behind this is SWR is unsure about if the next cursor is stable.

Imagine a timeline-like (Twitter/Facebook/GitHub) application, where new items will be appended to the first page. Now if there’re 3 pages loaded already, when hitting “Load Next”, SWR doesn’t know if there’s any new item in the first page. That’s why it has to revalidate the first page.

Since the entire list is cursor-based, SWR needs to refetch the second page if the first page has updated, and then the third page, … If it skips revalidating and only load the new page, it’s possible that you’ll miss the new item, have duplicates or miss old items (depending on the pagination API). So for correctness, SWR tries to revalidate the first page.

We can think about a new option in SWR to prevent revalidation of the first page when changing the page size, but I’m not sure if it’s a good thing for the applications’ UX.

[dkryptr]

That makes sense why the first page would be refetched.

Using Reddit infinite-scroll as an example: if there are three pages and the fourth is asked for, the first page needs revalidation. If the first and second pages change, the user might scroll back up to revisit a post and see something they hadn’t scrolled past earlier. It could also cause a content shift if something in their viewport changes because of revalidation.

But you you also brought up a good point about duplicates if revalidation doesn’t occur.

Thanks for walking me through this. I think it comes down to how the backend systems are serving pages to begin with. Because of that I don’t think we need to keep this open because SWR’s behavior makes sense.

[msnegurski]

Would still be great if there was an ability to disable this behaviour. Cursor based pagination kind of already takes care about it, and in some usecases it doesn't make sense. If I am on 20th page, useSWRinfinite makes 20 requests before loading next page, which could take a lot of time.

Reading the documentation, I was thinking that revalidateAll flag is what disables this behaviour, but it either doesn't work or is used for something else.

[sanders-vag]

I am also interested in disabling this behavior, could this be considered? Thanks!!!

[shuding]

I reopened and changed it to a feature request. 👍 If the API is cursor based it makes sense to have this option.

[tomaszczura]

I am interested on that too... We have items which won't be changed as often as reddit, but loading first page over and over again will lead to a bad UX - when user sees a loader, we have to load first page (which often is not visible), and then the one user wants to see - so user has to wait twice longer than it's necessary.

[shuding]

There is now a revalidateFirstPage option in swr@beta 🎉

[swushi]

Ah, this is not a problem I would have even thought of. Thanks for the write ups, and thanks for adding the option, although I agree with you that it is not needed unless using cursor based pagination.

[easyrun32]

I switched over to version swr@^0.3.0-beta.6. I don't see revalidateFirstPage include in version@1.0.0 ........

[shuding]

@easyrun32 It's included in the latest beta, not 1.0.0. Please run npm i swr@beta to upgrade.

[easyrun32]

@shuding ahh okay i got confused with the beta versions. I'll upgrade thanks!