-
-
Notifications
You must be signed in to change notification settings - Fork 516
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(openapi-react-query): support for useInfiniteQuery() #1881
Conversation
|
Is there any reason not to introduce this? |
@tommymarshall @jungwoo3490 this pull request does not seem to be ready to be merged as tests are still failing. And with the latest changes it now has conflicts with main branch. I would be happy to review a pull request introducing those changes with successful tests and resolved conflicts. |
Looks like it it's a build error with existing code -- worth re-running or getting the branch up-to-date @jungwoo3490 ? |
@kerwanp @tommymarshall |
Thank you for helping out @jungwoo3490! |
da3a024
to
5b61eea
Compare
@kerwanp @drwpow @tommymarshall |
I am confused, how do you use the |
When will be released? Any news? |
{ | ||
...baseOptions, | ||
initialPageParam: 0, | ||
getNextPageParam: (lastPage: any, allPages: any[], lastPageParam: number, allPageParams: number[]) => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to add getPreviousPageParam
here too or do we get it by default via baseOptions
?
Hi all, this hook is part of the core tanstack query and is one of the main reasons why devs choose tanstack query as opposed to other libs, I see a lot of work has been done already (Many thanks for them!) but we're wondering if we can help in anyway to have this merged? I, for one, would be very happy to help. Thanks. |
I managed to hack together a working implementation with a few tweaks from what has been done here. I quickly extracted this from some production code, so it will take some effort to get working for individual or project use cases. This implementation makes some assumptions about the page param being in the query params rather than the body of a POST request. There are a few ignored types, the generated I know I have found a way in the past to convert a dot-separated string into an object path with TypeScript, something like that might also work for the page param so it doesn't need to be a function call, but could still support different params sources. https://gist.github.com/awmichel/0e3aa3d5df6f7891e794895d2c695107 Edit: Ahh, yes, this StackOverflow post has some good references for strongly typed nested object paths. https://stackoverflow.com/questions/77976781/typescript-type-for-getting-all-nested-key-paths-of-an-object-including-arrays |
Thanks, this is really cool! Does the page param work only for query params, or can you use this for JSON bodies too? |
@musjj It only works for query params, but line 60 of the gist is where the page param is being merged into |
Hey guys, I continued this PR here #2117, I really need this feature so any reviews are welcomed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding this! The tests look good to me. I’ll merge this as a precursor to #2117
Changes
close #1828
I added
useInfiniteQuery()
toopenapi-react-query
.How to Review
Any feedback is welcome. I'll review it and make updates!
Checklist
docs/
updated (if necessary)pnpm run update:examples
run (only applicable for openapi-typescript)