Prevent double fetching when force refreshing paginated views#1637
Prevent double fetching when force refreshing paginated views#1637jeffvli merged 5 commits intojeffvli:developmentfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Seems like that behavior might have been there as long as this code, it wasn't as noticeable in 1.2.0 for example (flashes more quickly) but recent updates made the render slower which makes the issue more noticeable CleanShot.2026-02-02.at.10.32.03.mp4 |
|
I opened a PR to fix the performance regression that made that bug more apparent in this PR |
|
I believe the two fetches you're noticing is actually:
It's more apparent if you're not on page 1 of the list, as the listCount query is always run on the first page. |
Ah yes indeed. Still, it feels like the listCount query shouldn't refresh the UI in the case of a |
|
Yep, I needed to add a condition to exclude this behavior specifically for random 0af5ff6. The function was setting page data based on the list count fetch to improve the initial load time of the list which usually requires sequential fetches for the count and then the actual data. |
2 participants
This fixes a bug I recently noticed when refreshing the Albums view with the random sort, it seems the
refreshmethod initem-list-paginated-loader.tstriggers two network requests instead of one. This is usually fine1 in views where two requests with the same arguments will return the same result but this is visible on lists with a random sort, as shown in this recording I took earlier today.CleanShot.2026-02-02.at.09.50.08.mp4
This PR fixes that by not calling
invalidateQueries()when passingforceto therefreshmethod, which results in only one network request as expected. My react-query chops are a bit rusty so perhaps this isn't how you're supposed to fix that issue, happy to adjust if necessary.Footnotes
Albeit not optimal because the first request still happens and isn't being cancelled like it probably should. ↩