-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Writing to cache make an api call to fetch data. #6872
Comments
I'm experiencing the same issue. Also sometimes the data that is returned from the server overwrites my cached data. But I could not figure out yet how to reproduce this behavior, it seems very random. Edit @ShadabFaiz check out this comment, it'll probably solve your issue. |
I too am having this exact issue. However the integrated updating with |
For what it's worth, I've resorted to this workaround:
Manually specifying the merging policy seems to bypass default re-fetch behavior. |
Let us know if this is still a concern with |
Scenario:
This is my query:
This returns an array of objects containing 3 fields:
name
,id
,short_name
along with a__typename
. Assume the __typename for these objects aregetTODO
. This is how i'm getting the data from Server:Now I want to update the data in cached array.
Important point to mention here is that the
__typename
returned after creating a ToDo is different than the one already in cache.Now in the array updatedTodoList, the last object contains addition keys
description
andorganisation
along with different__typename
. When the cache.writeQuery is execute, the useQuery is also run making an additional unnecessary api call. If I remove the new key from the latest todo object, then no api call is made after writing into the cache.Intended outcome:
Writing to cache should not make any api call.
Actual outcome:
Writing to cache make any api call.
How to reproduce the issue:
Mentioned in the scenario
Versions
"@apollo/client": "^3.0.2",
"graphql": "^15.3.0",
Apollo CLient Configuration
The text was updated successfully, but these errors were encountered: