Repository navigation
Allow pageParam to be a string within generated infiniteQueries #146
Description
Activity
- added a commit that references this issue
on Jul 18, 2026 Fixed in v3.0.0.
The generator now resolves the page parameter's type from the schema — including through type aliases — and emits a matching type in all three positions instead of hardcoding
number. For a spec where the cursor isCursor: { type: string }:queryFn: ({ pageParam, signal }) => listItems({ ...clientOptions, query: { ...clientOptions.query, page: pageParam as Cursor }, ... }) initialPageParam: "1", getNextPageParam: (response: unknown) => (response as { nextPage: Cursor }).nextPage,
No
as numberon the string path, andinitialPageParamis quoted so it stays a string.Two things worth knowing for a cursor-based API, since a default of
"1"is rarely meaningful as a cursor:--initialPageParam ""emitsinitialPageParam: ""--omitInitialPageParam(added in v3) omits the page parameter from the first request entirely, which is usually what a cursor API wants — the server returns the first page when no cursor is supplied
Available on
latest(npm i @7nohe/openapi-react-query-codegen@3). Thanks for the report, and sorry it took a while.
Describe the bug
Our API uses string as page parameters, such as base64 encoded global ids, however when generating infinite queries where the type of pageParam is not a number within the schema
To Reproduce
openapi-rq --pageParam nextPageKey --nextPageParam nextPageKey -i specification.json -c axiosqueries/infiniteQueries.tsfile for type errorOpenAPI spec file
Would like to keep private
Expected behavior
If the schema defines the page token as a string then the generated types should also require a string.
Screenshots
Type Error:
Schema:
Additional context
N/A