hey-api
TanStack Query plugin
Description
Hey guys! I saw that the tanstack query generation is coming soon which is awesome. We are planning to migrate our project to use openapi-ts with tanstack-query. In order to avoid double work in our side when should we expect this feature to be shipped? Cheers!
Hey @sahinkutlu, would generating queryOptions() objects be enough to start?
@mrlubos is there any WIP on this? overall I'm having a good time using fetch API with tanstack query but there are some pain points that.. I'm sure you're aware of given that this is on the roadmap :slightly_smiling_face:
Yep, I did have a look at it, might prioritise it actually. Will queryOptions() objects be enough for you @vinnymeller?
Hey @sahinkutlu, would generating
queryOptions()objects be enough to start?
Hi @mrlubos! Yes generated query options would very nice 👍 When do you think it will be released? Cheers!
It would be nice to have. I'm thinking about writing my generator, but if it's implemented in your library it would be just awesome!
@mkeyy0 soon https://github.com/hey-api/openapi-ts/blob/main/packages/openapi-ts/test/snapshots/test/generated/v3-hey-api-client-fetch-plugin-tanstack-react-query/@tanstack/react-query.gen.ts.snap
I hope that other framework versions of TanStack, like Vue, will also be supported.
@brmdbr Hopefully within 2 weeks, but if you want to test drive it earlier, send me a message on Discord/email/Twitter/LinkedIn and I can walk you through it (in exchange for some feedback 😈)
Support for React, Solid, Svelte, and Vue done, currently undergoing testing. If anyone wants to try it out early, add this to your configuration file
for React
plugins: ['@tanstack/react-query']
for Solid
plugins: ['@tanstack/solid-query']
for Svelte
plugins: ['@tanstack/svelte-query']
for Vue
plugins: ['@tanstack/vue-query']
and feel free to open a new issue if you run into any problems! I don't really expect the APIs to change, but it has not been thoroughly tested (except for React), so you never know!
@mrlubos It would be nice if we could override some of the tanstack query options. I prefer to set some options manually, such as enabled and staleTime, and this would allow for those manual changes. I haven't looked into the query key part of it too much, so not sure if that would work with the typing, but having the ability to add additional keys would be appreciated.
Here is my idea on how to do this with adding the tanstackQueryOptions as a parameter.
export const serverGetOptions = (
options: Options<ServerGetData>,
tanstackQueryOptions?: Omit<UndefinedInitialDataOptions<any, Error, any, any[]>, "queryFn">,
) => {
return queryOptions({
...tanstackQueryOptions,
queryFn: async ({ queryKey }) => {
const { data } = await serverGet({
...options,
...queryKey[0].params,
throwOnError: true,
});
return data;
},
queryKey: [
{
params: createQueryKeyParams(options),
scope: "serverGet",
},
...(tanstackQueryOptions ? tanstackQueryOptions.queryKey : []),
],
});
};
@RobertOstermann that's fair, I will need to improve types to unlock this feature. In the meantime, you can simply spread the response from this function onto useQuery() and add your options there.
useQuery({
... serverGetOptions(),
enabled: false,
})
I was able to do that for most of the options, but struggled to get it working with queryKey, might just be user error though.
@RobertOstermann what kind of query key are you passing? I would expect TypeScript to complain if it doesn't match the expected shape. That might need to be improved, why are you needing to pass your own query key?
I was trying to pass in a number. Tried adding it as a new element at the end of the query key array, but no luck. I prefer to pass in my own query key so I can easily invalidate several queries, all which share that same query key, when a mutation is complete. I think it not matching the expected shape was the issue.
Also, thanks for all your hard work on this! Super useful.
useQuery({
... serverGetOptions(),
queryKey: [...serverGetOptions().queryKey, idNumber],
enabled: false,
})
@RobertOstermann we should talk about that use case, perhaps separately. Query key design is important. I've also heard from others they need URL base as part of it so they can target by the client which made the request.
When using bundle: true, the code doesn't seem to generate correctly. Maybe it's related to #939 ?
Thank you for this nice work. Can you confirm that services: { asClass: true, } will not work with the plugin (yet)?
@holtgrewe The question is what do you imagine/understand by that? The plugin is a separate output so the way you generate services does not have an impact on it
@mrlubos the result appears to be incompatible as it does not generate the ClassNameService. prefix to the calls. But never mind, I adjusted away from services: { asClass: true }.
@holtgrewe Ah got you. That should be fixed, thanks for pointing it out
@SimenB yes, there are no plans to support the old clients at this time