Support for multiple InfiniteQueryParams

[fr3fou]

As of now the library only supports a single InfiniteQueryParam -

In some cases endpoints may require 2 (or more) params, meaning one can't use a generated hook, instead they have to fallback to manually calling useInfiniteQuery -

useInfiniteQuery(
    "home",
    ({ pageParam }) =>  myPaginatedEndpoint({ foo: pageParam.fooCursor, bar: pageParam.barCursor }),
    {
      getNextPageParam: (lastPage) => ({
        fooCursor: lastPage.fooCursor
        barCursor: lastPage.barCursor,
      }),
    }
  )

I propose adding useInfiniteQueryParams which is an array, in order to support multiple keys at a time

[mainfraame]

I'm seeing the same thing happen. it looks like getNextPageParams ends up not getting passed as part of the params to the client

[vezaynk]

The proper fix for this would be to make a the param a function instead of a string, and let it be passed as-is to react-query.

[createdbymahmood]

any updates?

[anymaniax]

Sorry I cannot check anything before mid September

[majkl-zumberi]

updates on this issue? it would be very nice to handle multiple query params

[melloware]

@georgiev-anton is working on this.

[georgiev-anton]

yes in this pr #947

[victorboucher]

This is actually a different issue to the one you've fixed in #947 @georgiev-anton. Since only a single useInfiniteQueryParam key is supported in the output config, you could never use any other param for your infinite queries. I'd actually propose making the useInfiniteQueryParam property entirely optional, and when its not being supplied just allowing you to return an object from getNextPageParam which returns any input params of the given query. Or to be able to override it by returning an object with the desired params. But please feel free to give me your thoughts about this!

[dawsonbooth]

We addressed this issue by removing the useInfiniteQueryParam global setting, wrapping the generated query hook, and building our own queryFn to override the generated one. This lets us have separate queryFn options and thus separate page parameters for different infinite queries.

Not the cleanest fix, but it works until there's an update made to the settings.

[pycraft114]

we need this feature @dawsonbooth can you share us the workaround?

[jordan-rigo]

Do I have to provide "useInfiniteQueryParam" in the config file? I would need infinite query for a single API not for all of them Can I not add it to the config, and provide this somehow when trying to use the hook?

[dawsonbooth]

@pycraft114 Sure! Sorry, just now seeing this.

Our case had to do with using a timestamp cursor to fetch an infinite list of notifications. Instead of messing with the infinite query params that we had been using for all other queries, we built our own wrapper around a normally generated query hook.

import {
  GetNotificationsParams,
  Notifications,
  useGetNotificationsHook,
  useGetNotificationsInfinite,
} from './codegen/generated'
import { useCustomInstance } from './codegen/custom-instance'
import { CustomError } from './codegen/custom-error'
import { QueryFunction, UseInfiniteQueryOptions } from 'react-query'

const useGetNotificationsInfiniteQuery = (
  params: GetNotificationsParams,
  options?: {
    query?: UseInfiniteQueryOptions<
      Awaited<ReturnType<ReturnType<typeof useGetNotificationsHook>>>,
      CustomError,
      Notifications | null
    >
    request?: Parameters<ReturnType<typeof useCustomInstance>>[1]
  },
) => {
  const getNotificationsHook = useGetNotificationsHook()

  const queryFn: QueryFunction<
    Awaited<ReturnType<ReturnType<typeof useGetNotificationsHook>>>
  > = ({ pageParam }) =>
    getNotificationsHook(
      { ...params, timestamp: pageParam || params?.['timestamp'] },
      options?.request,
    )

  return useGetNotificationsInfinite(params, {
    query: {
      queryFn,
      getNextPageParam: (lastPage, _) => lastPage?.notifications?.at(-1)?.timestamp,
      ...options?.query,
    },
  })
}