lukemorales/query-key-factory

Typing: staleTime not available as prop in static query

Dammic opened this issue · 4 comments

Dammic commented

Hello!

I ran into a small issue when trying to use the library.
It seems that the staleTime is not available in types when using a static query without any queryKey, while it works just fine when the query is dynamic:

Screenshot 2024-01-18 at 13 18 01
Screenshot 2024-01-18 at 13 18 38

Is this behaviour intended? I would assume the props should be similar in both cases.
Thanks in advance for reply!

@Dammic not sure if you've figured this out by now, but the typings are misleading either way - helper functions of createQueryKeys only return queryFn and queryKey. All other react-query useQuery options you may pass (staleTime, gcTime etc) will be ommitted.

This can be seen in the implementation:

const queryOptions = {
queryKey: innerKey,
queryFn: result.queryFn,
};

@lukemorales I think this behavior should be documented, or support added for all other useQuery() options being passed through, as current typings wrongly indicate this is supported and one may lose a bit of sanity trying to figure out why e.g queries aren't always getting fresh data when using {gcTime: 0, staleTime: 0}

@gomesalexandre the behavior is documented, there are no examples with options other than queryKey and queryFn, and nowhere in the documentation it is told that every query option is supported, every attempt of using anything else other than queryKey and queryFn it's the user to blame.
With that said, the issue is that typescript widens the type of the object as long as some of them match the expected format (with queryKey and/or queryFn) and it allows extra keys not defined before. But I'm already working on a rewrite of the lib to allow all queryOptions to be defined and problems like this will not happen again

While the major version is still not out there, I released v1.1.3 that makes the object returned in a dynamic query super strict to the only expected keys. Hope that prevents any future confusion

That was super fast @lukemorales, thank you! 👑