Skip to content

Conversation

Ephem
Copy link
Collaborator

@Ephem Ephem commented Jul 14, 2020

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.

…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
@vercel
Copy link

vercel bot commented Jul 14, 2020

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/tannerlinsley/react-query/bekkd86ni
✅ Preview: https://react-query-git-fork-ephem-fix-ssr-cache-default.tannerlinsley.vercel.app

@@ -8,16 +8,16 @@ import {
import { defaultConfigRef } from './config'
import { makeQuery } from './query'

export const queryCache = makeQueryCache()
export const queryCache = makeQueryCache({ frozen: isServer })
Copy link
Collaborator

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?

Copy link
Collaborator Author

@Ephem Ephem Jul 15, 2020

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.

Copy link
Collaborator

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 ;)

@tannerlinsley tannerlinsley merged commit 923c5d4 into TanStack:master Jul 17, 2020
@tannerlinsley
Copy link
Collaborator

🎉 This PR is included in version 2.5.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

tannerlinsley pushed a commit that referenced this pull request Jul 17, 2020
…by default in node (#749)

Fix so the default behaviour matches the one described in the Readme.
Add tests for the above behaviour.

Closes #706
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Default makeQueryCache server behaviour does not match Readme
2 participants