-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Fix makeQueryCache default caching behaviour in node #749
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
Conversation
…by default in node Fix so the default behaviour matches the one described in the Readme. Add tests for the above behaviour. Closes TanStack#706
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/tannerlinsley/react-query/bekkd86ni |
@@ -8,16 +8,16 @@ import { | |||
import { defaultConfigRef } from './config' | |||
import { makeQuery } from './query' | |||
|
|||
export const queryCache = makeQueryCache() | |||
export const queryCache = makeQueryCache({ frozen: isServer }) |
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.
Hmm. I had someone trying to use ReactQuery in the CLI the other day. This would make that default to frozen, correct?
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.
Yes, the global cache will still be frozen by default in all server environments in this PR since changing that behavior would regress #70 and in my eyes be a breaking change.
I would suggest not only that we change this default behavior in the next major, but actually that we get rid of the global cache entirely (at least on the server side, possibly client too). So instead of making the global cache available for CLI-development, we push everyone to create their own cache.
Creating a queryCache
via makeQueryCache
is trivial and you can easily just export that as a global cache yourself if that is what you want. What we would gain from this is that developers would explicitly have to create a cache somewhere, making it clear that whatever you fetch into this cache will be shared. This would let us get rid of the frozen/unfrozen concept, streamline the behavior and still make it hard to/avoid accidentally leaking data cross-request.
ADD: If this is something we decide to do, we could add a deprecation-log in the development build to get people prepared for it.
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.
While I totally wish I had avoided the singleton from the start, it's going to be very difficult to get away from in the future. Even IMO, it's very convenient. I'd like to avoid it as long as possible ;)
🎉 This PR is included in version 2.5.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Closes #706
This PR makes it so caches returned from
makeQueryCache
will always be unfrozen, and therefor cache data, by default. This now includes on the server.The global cache on the server is still frozen by default and does not cache data, this is to avoid leaking data across requests as per #70.
This makes it so the behaviour of
makeQueryCache
matches the one described in the Readme.I also made the tests around this more explicit.