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

previousQueryResult object is empty in updateQuery when changing query variables while the fetchMore is in progress #7241

Closed
Allaoua9 opened this issue Oct 26, 2020 · 4 comments
Assignees

Comments

@Allaoua9
Copy link

Allaoua9 commented Oct 26, 2020

Intended outcome:
Hypothesis:
For simplicity sake, let's say, all queries take 500ms.

Steps to reproduce :

  1. Make a query with variables. and wait for it to resolve (500ms).
  2. Call fetchMore, to get next page (500ms).
  3. After 20ms (fetchMore still in progress), Change the state that holds the variables of the query => the query should be replayed.

Actual outcome:
When the updateQuery is called, the previousQueryResult is empty.

How to reproduce the issue:
Here is a reproduction of this bug

https://codesandbox.io/s/reproduction-for-react-apollo-7241-with-successful-response-forked-lvypl?file=/src/ThingsList.jsx

Versions
@apollo/client 3.2.5

@benjamn benjamn self-assigned this Oct 26, 2020
@benjamn
Copy link
Member

benjamn commented Oct 26, 2020

@Allaoua9 Thanks for the reproduction!

When you change the filter argument for the original query by calling setFilter("New Filter"), you trigger another cache read, which fails to provide useful data because of the change in filter.

Since it sounds like you don't want the change of filter argument to invalidate previous results for Query.thingsList, you can let the cache know the filter argument should be ignored when reading/writing the field value:

const client = new ApolloClient({
  link: new SchemaLink({ schema: executableSchema }),
  cache: new InMemoryCache({
    typePolicies: {
      Query: {
        fields: {
          thingsList: {
            // By default, this configuration would include all arguments in the field key,
            // which would be equivalent to keyArgs:["filter", "page"]. By specifying
            // keyArgs: ["page"] we are effectively removing the "filter" argument:
            keyArgs: ["page"],
          },
        },
      },
    },
  }),
});

You could also probably use keyArgs: false here to ignore the page argument as well, since it looks like you want the original query to receive the complete list of data, without splitting it up into separate pages.

See #7175 for some new pagination documentation that we've been working on, in case you want a whole lot more detail about how this system works.

@Allaoua9
Copy link
Author

Thanks for the answer @benjamn !
I'll take a look on the new doc :)

@hwillson
Copy link
Member

Let us know if #7241 (comment) didn't help. Thanks!

@Allaoua9
Copy link
Author

Allaoua9 commented Jun 14, 2021

@hwillson it dit help thank you !

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 15, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants