apollo-client: useQuery fails to return cached data when variables are changed

Consider the following queries

useQuery(POSTS, {
  variables: {
    offset: currPage * 20
  }
})

where currPage is a React local state variable. It will get updated when user paginates

Intended outcome:

When currPage=1, new data is fetched, when currPage=2, new data is fetched… When user paginates to the previous page (page 1), because query with currPage=1 is already fetched, it should just read the cache

Actual outcome:

When user paginates from page 1 to page 2, new data for page 2 is fetched, however, when user paginates back to page 1, cache is not read, data is still displayed for page 2

How to reproduce the issue:

Versions

@apollo/client: ^3.0.0-beta.14
react-apollo: ^3.1.3

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 16
  • Comments: 18

Most upvoted comments

I am just surprised no one from Apollo team has responded to this issue. It seems to be a big bug to me 😦

@jsmircic I don’t think this is by design. First, it works on previous versions. Second, If a query with a given variable has already been fired, data should be cached so that when this query is fired again, no network request should be needed, data should be returned from cache.

fetchMore is used for fetching more data (new variables). However, this issue is related to read cached data, not fetch more data

@benjamn @hwillson

The problem doesn’t exist with version 3.0.0-beta.7 but was introduced in 3.0.0-beta.8

Hopefully this is not intended behavior, as simply updating the variables in the useQuery call allows for declaratively representing data dependencies, consistent with React principles, whereas forcing to use fetchMore and manually update the cache is very imperative and tedious, and defeats purpose of having the library manage these things for you.

Here is a simple codesandbox reproducing the issue.

Notes:

  • The actual request made to the graphql endpoint has the correct variables and response.
  • Using fetchPolicy: no-cache avoids the issue.
  • Using network-only does not, however, even though none of them is supposed to read from the cache (it should only differ from no-cache in that it writes to the cache).

We’re having the same problem. As a temporary workaround we’re using no-cache fetchPolicy on queries affected by this.

EDIT: We had to useno-cache not network-only as first stated.

After migrating to3.0.0-beta.24 the issue still exists

We are also experiencing this issue with 3.0.0-beta.16 Using a query that get data based on tab value works the first time but switching back it will keep the wrong cached value.

Example that fail:

POSTS = gql`
query PostQuery($id: ID, $tabValue: number) {
  post(id: $id) {
    authors(filter: $tabValue) {
      id
    }
  }
}
`

useQuery(POSTS, {
  variables: {
    id: 1,
    tabValue: tabIndex
  }
})

Verified that version 3.0.0-beta.24 solved the bug, closing this issue

Facing the same issue. Even manually calling refetch() doesn’t work. The only workaround is to avoid the cache, setting the fetchPolicy to network-only.

EDIT: Is it really only introduced recently? I’ve spent hours looking into this now and it seems like a lot of people are facing this issue, but just phrasing it differently (“onCompleted() / refetch() / setVariables not called”, setting notifyOnNetworkStatusChange: true).

https://github.com/apollographql/react-apollo/issues/2177 https://github.com/apollographql/react-apollo/issues/2202

The docs link to an example that relies on triggering a query execution by changing the query variables: https://www.apollographql.com/docs/react/v3.0-beta/data/queries/#caching-query-results https://codesandbox.io/s/n3jykqpxwm Also, fetchMore is designed to allow to merge query result when variables change. A query with changed variables is stored as new query in the cache, which may not be what you want for pagination.

So i also think this is a bug. It’s a bit strange that this issue it not marked a bug (or as confirmed).