Apollo-client: [3.0] useQuery does not hit the cache when variables change

Created on 13 Jan 2020  ·  6Comments  ·  Source: apollographql/apollo-client

I know there are similar issues open already, but couldn't really come to any conclusions after reading them, also I thought the reproduction below could help.

related: #5659

Intended outcome:
When variables change in useQuery, Apollo Client should repeat the full request lifecycle exactly as for the initial set of options, including checking the cache for possible hits.

I am using a TypePolicy to get the results from the cache, not sure if that is important to this issue.

Actual outcome:
on component mount, useQuery gets the data from the cache/network. if query variables are changed, useQuery refetches the query (if permitted by fetchPolicy), but never checks the cache with the new variables:

  • fetchPolicy: 'cache-and-network'
    shows the old value while waiting for new network response, even if the new values are already in cache.
  • fetchPolicy: 'cache-only' or 'cache-first'
    shows the value corresponding to the first set of variables forever, never goes back to the cache to update the result.

How to reproduce the issue:
reproduction here: https://codesandbox.io/s/dreamy-ride-gns90

The sandbox includes one query that fills the cache, and then another one that can be executed with changing variables. This second query is configured in typePolicies to grab results from the cache. The query results do not get updated from the cache after the first request.

Versions
"@apollo/client": "3.0.0-beta.21",
"graphql": "14.5.8",
"react": "16.12.0",
"react-dom": "16.12.0",
"react-scripts": "3.0.1"

has-reproduction ✔ confirmed 🐞 bug 🛬 fixed-in-prerelease

Most helpful comment

@jcane86 This should now be fixed if you update to @apollo/[email protected] (thanks to #5791), judging from your reproduction.

All 6 comments

@jcane86 Just wanted to say thanks for the excellent reproduction! Not fixed just yet, but I think I know what's (not) happening.

@benjamn no worries mate, thank you for your work on the library. v3.0 is looking great BTW

@jcane86 This should now be fixed if you update to @apollo/[email protected] (thanks to #5791), judging from your reproduction.

@benjamn brilliant, thanks for the quick fix! I'll give it a go in my project later and come back if anything goes wrong, but yeah, looks solved to me!

Resolved by @apollo/[email protected] - closing, thanks!

6017

Was this page helpful?
0 / 5 - 0 ratings