useInfiniteQuery vs useQuery

[quickstark]

Relatively new to useQuery and just had a couple "appropriate use" Qs that I didn't see obvious answers to in the Discussions.

A bit of context. I am accessing a paginated API with a tokenized next page URI that must be passed to grab the next page (as opposed to a simple ?Page=2 ).

I have this working with useInfiniteQuery via getNextPageParam: (lastPage, pages) => lastPage.next_page_uri

1. First question: Is there a better way to handle this kind of pagination? (e.g via useQuery and Pagination ?)

A little more context. The fetched data is ultimately being rendered by an AntD Table which takes an array as its dataSource. Normally I just set to a useState variable that I update from the results of a recursive function. useInfiniteQuery returns data as an array of pages.

In this case, the data I need from the API is located in it's own array. So, to correctly populate the table, I'm consolidating the multiple "arrays within pages" using data.pages.map((page) => page.messages).flat() but this just feels strange.

2. Second question: is this an appropriate way to handle populating a 3rd party component given how useInfiniteQuery is returning data?

Something about the way I've opted to solve this feels weird to me ...

Any comments welcome. Thanks, Dirk

[TkDodo]

Is there a better way to handle this kind of pagination?

you could always paginate "manually" with useQuery and keepPreviousData. if your query data contains the "link" to the next page, it should be as simple as:

const [page, setPage] = React.useState('someWayToIdentifyTheFirstPage')
const queryInfo = useQuery(['data', page], () => fetchData(page), { keepPreviousData: true })

<button onClick={() => setPage(queryInfo.data.next_page_uri)} disabled={queryInfo.isPreviousData || !queryInfo.data.next_page_uri}>Next</button>

is this the appropriate way to handle populating a 3rd party component given how useInfiniteQuery is returning data?

you can always do a custom hook and return the data in the structure that you prefer. perfectly fine to flatten out the array of pages on that level.

[quickstark]

Thanks for a speedy response! Makes perfect sense. Seems like 6 v 1/2 dozen ... except perhaps a more streamlined data value when using useQuery

[quickstark]

@TkDodo just in case anyone else asks the same, would you mind validating this?

One difference I noticed between useQuery and useInfiniteQuery. With useQuery, I had [incorrectly] assumed the keepPreviousData prop meant that useQuery would literally "keep" the prior fetched data and add it to the original, but it doesn't appear that's the intent (whereas useInfiniteQuery does persist the prior pages):

From useQuery Paginated Queries:

When the new data arrives, the previous data is seamlessly swapped to show the new data.

[TkDodo]

it's a bit different than that:

• if you do useQuery with changing query keys and keepPreviousData: true, you will get separate query cache entries for each page. you will usually only have access to one page at the time. That's why paginated queries are good to implement that way.
• with useInfiniteQuery, you will get one cache entry which contains multiple pages. refetching and invalidation will always refetch all pages. You will also always have access to all the pages. This is better for infinite scrolling.

keepPreviousData can also be used with infinite queries. All it does is: If the query key is changing, I'm returning the data from the previous key's cache entry and the isPreviousData: true flag. if you have an infinite list of done todos and you change it to an infinite list of open todos, you are basically switching between two infinite queries, and you can use keepPreviousData to smoothen that transition. keepPreviousData is not something unique for paginated queries. Pages are just one use case of it - filters would be another one :)