Suggestion: improve ergonomics of *InfiniteOptions
types
#8484
Replies: 2 comments 11 replies
-
using the defaults doesn’t really help much because using them will make features where type inference is necessary, like We use Moving to a discussion. |
Beta Was this translation helpful? Give feedback.
-
Hijacking this a bit because I'm having a similar problem but even passing the types isn't helping. I'm trying to convert a component to TypeScript and I cannot get type generics to work with import React, { ReactNode } from 'react';
import {
DefaultError,
InfiniteData,
infiniteQueryOptions,
QueryKey,
useInfiniteQuery,
} from '@tanstack/react-query';
type TestPageParams = {};
export interface InfiniteScrollProps<T, P extends TestPageParams> {
children: (data: InfiniteData<T, P> | undefined) => ReactNode;
queryFn: (pageParam: P) => Promise<T>;
queryKey: QueryKey;
initialPageParam: P;
}
export const InfiniteScroll = <T, P extends TestPageParams>({
children,
queryFn,
queryKey,
initialPageParam,
}: InfiniteScrollProps<T, P>) => {
const { data } = useInfiniteQuery(
infiniteQueryOptions({
queryKey: [...queryKey, initialPageParam],
queryFn: ({ pageParam }) => queryFn(pageParam),
initialPageParam,
getNextPageParam: (lastPage, allPages, lastPageParam) => lastPageParam,
})
);
return <>{children(data)}</>;
}; I'm getting "TS2345: Argument of type unknown is not assignable to parameter of type P. P could be instantiated with an arbitrary type which could be unrelated to unknown" on the
Changing the code to What am I missing here? It feels like Edit: tried using OP's method and having the same issue: const queryOptions: UnusedSkipTokenInfiniteOptions<T, P> = {
queryKey: queryKey,
queryFn: ({ pageParam }) => queryFn(pageParam),
initialPageParam,
getNextPageParam: (lastPage, allPages, lastPageParam) => lastPageParam,
}; |
Beta Was this translation helpful? Give feedback.
-
Describe the bug
The docs suggest using
infiniteQueryOptions
to abstract infinite query options. For example:However, when using TypeScript's isolated declarations (
isolatedDeclarations
), all module exports must have type annotations. For this reason it would be preferable to use a type annotation rather than theinfiniteQueryOptions
type constructor.The problem with this, however, is it's very verbose:
Except for the first and last type parameters provided to
UnusedSkipTokenInfiniteOptions
, all the others could theoretically just use the defaults. However, we're forced to provide them because we need to provideTPageParam
(the last type parameter), otherwise it would default tounknown
.Given more TypeScript users will likely be looking to enable isolated declarations in the future and thus be required to add type annotations, I wonder if we could make these types more ergonomic.
One idea would be to move the position of the
TPageParam
type parameter in the*InfiniteOptions
types, so we can benefit from defaults. For example, if it was moved from last to second position then the example above would look much better:Your minimal, reproducible example
N/A
Steps to reproduce
N/A
Expected behavior
N/A
How often does this bug happen?
None
Screenshots or Videos
No response
Platform
N/A
Tanstack Query adapter
None
TanStack Query version
N/A
TypeScript version
No response
Additional context
No response
Beta Was this translation helpful? Give feedback.
All reactions