Skip to content
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

Typing: staleTime not available as prop in static query #83

Open
Dammic opened this issue Jan 18, 2024 · 4 comments
Open

Typing: staleTime not available as prop in static query #83

Dammic opened this issue Jan 18, 2024 · 4 comments
Assignees
Labels
will be resolved in a major release Feature or bug will be resolved in the next major release
Milestone

Comments

@Dammic
Copy link

Dammic commented Jan 18, 2024

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!

@gomesalexandre
Copy link

gomesalexandre commented Feb 8, 2024

@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}

@lukemorales
Copy link
Owner

@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

@lukemorales
Copy link
Owner

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

@gomesalexandre
Copy link

That was super fast @lukemorales, thank you! 👑

@lukemorales lukemorales added the will be resolved in a major release Feature or bug will be resolved in the next major release label Feb 12, 2024
@lukemorales lukemorales self-assigned this Feb 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
will be resolved in a major release Feature or bug will be resolved in the next major release
Projects
None yet
Development

No branches or pull requests

3 participants