I am using the latest version of react-apollo with meteor
Intended outcome:
I have a paginated list. I would like to add a reload button to this list. On reloadig, the current data should be erased, and new data should be fetched from the server on all pages of that list.
Actual outcome:
I have tried to trigger .refetch()
with this button. But it refetches only the current page. If other pages were visited before the reloading button is triggered, the data of those pages is stored in the store and is not refetched.
Triggering .resetStore()
resets the whole store and all queries on the page. Which is obviously an overkill...
My question is:
Am I using .refetch()
wrong? What would be the right approach?
Or am I using .resetStore()
wrong? Is it possible to reset the store of one specific query?
Thank you!
You could use fetchMore and instead of appending data like in the example you could have it replace the property you're changing:
http://dev.apollodata.com/react/pagination.html#numbered-pages
Please correct me if I am wrong. Since I am not using fetchMore()
right now. The results of my queries are not connected to each other, therefore refetch()
, refetches only the last query.
Instead, if I start using fetchMore()
, the results of the queries will be connected to each other (like get the data of the first, later get the data of the second page and so on...). In the case of refetch()
, the whole result of those queries will be refetched at once? Or only of the data that was fetched last, but the other data will at least be obsolete and discarded and fetched again if needed instead of taking it from the store?
The point of fetchMore
is that it allows receive some data from your server and then tack it onto existing data in your store. This is generally the "right" way to do pagination.
In this case, you can use fetchMore
to fetch each page (i.e. regular pagination) and then fire a single query that just refetches all of the items across each of the pages which can be fired by your reload button.
Is fetchMore
intended to be used for page-based pagination in the UI? It seems more designed for things like infinite scrolling... looking at the examples, it's not clear how one might implement a more traditional paginated view. I'm talking about this sort of thing:
Note that it's not guaranteed that a user will click "Next" - they might go from Page 1 to Page 5 and then to Page 3.
This issue has been automatically marked as stale becuase it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions to Apollo Client!
This issue has been automatically closed because it has not had recent activity after being marked as stale. If you belive this issue is still a problem or should be reopened, please reopen it! Thank you for your contributions to Apollo Client!
fetchMore really a solution for cursor-based pagination rather than offset-based. The example on the Apollo-Client documentation improperly exemplifies this behavior for the offset-based pagination. While fetchMore can be used, it definitely is not the correct solution here. The whole point of offset-based pagination is to minimize the amount of cached data and provide a bit more fine grained control for users, such as paginating through table records whereas fetchMore is a great continuous feed solution when data is streaming in.
so what should I use for offset based pagination?
I would like to know too how to do pagination where you can skip pages.
Although this has gone stale I believe the original issue still lacks a clear solution.
I am using fetchMore
for an infinite list and the use of refetch
causes the data of all pages to be cleared out and only the first page to be refetched.
I have created a reproduction to illustrate the problem: https://codesandbox.io/s/34zyo65my6
I am still experiencing the same problem. Have you guys found any workarounds for the offset based pagination?
Hi @furkanDogu,
The workaround I found for that problem was to use an internal cache to control which type of query I want to refetch.
E.g.
// Create a cache param in your gql schema
const { loading, error, data, refetch } = useQuery(GET_USERS, {
variables: {
number: page,
size: numPerPage,
cache: internalCache('userListPagination').toString(), // Get the cache value each time
},
notifyOnNetworkStatusChange: true,
})
// So when you change something, just renew the cache for that type of query.
// as soon as your query has a new value, the Apollo Client will automatically refetch
internalCache('userListPagination', Date.now())
It's been working well here so far, if anyone has something better, I want to know too!
Most helpful comment
Is
fetchMore
intended to be used for page-based pagination in the UI? It seems more designed for things like infinite scrolling... looking at the examples, it's not clear how one might implement a more traditional paginated view. I'm talking about this sort of thing:Note that it's not guaranteed that a user will click "Next" - they might go from Page 1 to Page 5 and then to Page 3.