fix(openapi-ts): fix generated infiniteQueryOptions not work with useSuspenseInfiniteQuery #3205
Conversation
Enhance the OpenAPI configuration to include pagination options and update the App component to utilize both infinite and suspense infinite queries for fetching pets by tags. Introduce new utility functions for infinite query handling in the generated client code.
|
|
|
|
@manudeli is attempting to deploy a commit to the Hey API Team on Vercel. A member of the Team first needs to authorize it. |
| .pretty() | ||
| .hint('@ts-ignore') | ||
| .prop('initialPageParam', $.object().pretty().as('any')) | ||
| .prop('getNextPageParam', $.func().as('any')) |
There was a problem hiding this comment.
This feels very dirty. Is the issue that the inferred type doesn't contain initialPageParam and getNextPageParam? Why not add a second argument and require them?
| tags: [], | ||
| }, | ||
| }), | ||
| getNextPageParam: (lastPage) => lastPage.map(({ name }) => name), |
There was a problem hiding this comment.
What would happen if you omit this line? Would the types not complain? Would the runtime code likely crash?
| }, | ||
| }), | ||
| getNextPageParam: (lastPage) => lastPage.map(({ name }) => name), | ||
| initialPageParam: { query: { tags: [] } }, |
There was a problem hiding this comment.
The other reason this smells is if you place this line BEFORE the generated options, it won't get applied. I think we either want to keep options as they were (not setting this property) or require this property if it's needed
2 participants
fix: #2931