Improve useInfiniteQuery type

[ArianHamdi]

Currently, the getNextPageParam function is required, but getPreviousPageParam is optional in useInfiniteQuery. In some cases, like messaging, we fetch the last page and only want to fetch previous pages, so having getNextPageParam required doesn't make a lot of sense. I would suggest creating a union to ensure that the user passes at least one of the functions, either getNextPageParam or getPreviousPageParam.

[TkDodo]

getNextPageParam is required because when refetching, we start at the first page and go forward from there

[vfa-tuanva]

@TkDodo
I encountered a problem with this approach. Based on my knowledge, when refetching, getNextPageParam will use the first value from the params list and then recalculates the param, which triggers a refetch with the recalculated value (also update new params list value instead of using the value from the original params list). This works fine when dealing with a simple field like page (where the page number just needs to increase or decrease). However, for more complex infinite queries that do not use a page number but instead use multiple fields like since and until (e.g., using until to get the newest messages from the server), which are based on the timestamp of the response content, it becomes difficult to implement useInfiniteQuery in this scenario.

[TkDodo]

why does it become difficult? If the server response includes since and until, you can just use those as a pageParam (it can be an object ...)

maybe show an isolated reproduction of what you're struggling with

[vfa-tuanva]

@TkDodo
Thank you for your feedback. Here is a snapshot of my code:

As you can see, the API searchEventsByChannelId does not receive page as a query parameter. Instead, it requires either since or until.

To get the message list, use the until timestamp to retrieve messages backward (exclusive) or the since timestamp to retrieve messages forward (exclusive).

Therefore, both getNextPageParam and getPreviousPageParam depend on the response data to generate the correct query parameters for the API.

This logic works fine in the normal flow. However, refetching breaks the logic because getNextPageParam recalculates the parameters list and incorrectly feeds these parameters to the API.

Currently, I am trying to find a workaround to split the code in getNextPageParam to use the original parameters list in case of refetching.

I am not confident in my English skills, so I apologize if there is anything unclear in my explanation.

[TkDodo]

getNextPageParam and getPreviouPageParam look fine. I'm struggling to understand why this breaks with refetching?