-
Notifications
You must be signed in to change notification settings - Fork 787
Refetch(with different variables) return old values if query variables already in cache #3335
Comments
@DerekHung Before I dig into this, can you confirm that you're using |
Hi @hwillson |
UPDATE: I've test by HOC method, It get the same problem at react-apollo@3.0.0 |
UPDATE: upgrade version to 3.0.1 and still get the same result. |
hi @hwillson I've found a way to avoid this problem, but this way cause another problem of ESLint warning & maybe anti refetch design. |
Intended to help troubleshoot #3335. Fixes 3335
@DerekHung I've looked into this, but haven't been able to reproduce it. Can you take a look at the test in #3434 to see if I'm understanding the problem correctly? If not, would you be able to put together a small runnable reproduction? |
) Intended to help troubleshoot #3335. Fixes 3335
Confirming this is still an issue |
I was able to use fetchMore({
variables: {
...newVariables
},
updateQuery(_, { fetchMoreResult }) {
return fetchMoreResult
}
}) edit: this seemed to cause some bizarre situations with the cache, so beware. It seemed like the cache was being updated for the previous query, still, despite the new variables. |
Hmm, that test @hwillson doesn't test for I have just also encountered this problem (on Following code const { data } = await refetch(); returns the data from the cache (that is stored there while Instead, I would expect that the promise that is returned by Am I right with this @hwillson ? (Currently it doesn't work like that) I can help writing the test case for it, and maybe the code fix as well. |
I met the same issue. It seems to be cache key field.
|
My solution was to actually memoize the function that the query was inside of to skip the query completely. The function was memoized based on the input parameters of the function since I could never get the cache key to respond to any other parameters except the ID |
The problem seems to be that the refetch function follows the fetch policy of its query. If the fetch policy is set as "cache-and-network" the refetch function seems to return the value from cache and then updates the value in the cache. There should either be a variable to set the fetch policy of the refetch function separately or the refetch function should by default follow the "network-only" fetch policy. |
I can confirm the same issue. I'm using For now, I've found out 2 possible workarounds to this:
const { data, loading, fetchMore } = useSomeQuery({
fetchPolicy: 'cache-and-network',
variables: {...},
})
fetchMore({
updateQuery: (prevQuery, newQuery) =>
newQuery.fetchMoreResult ? newQuery.fetchMoreResult : prevQuery,
})
const { data, loading, refetch } = useSomeQuery({
fetchPolicy: isOffline ? 'cache-and-network' : 'network-only',
variables: {...},
})
refetch() But some flexibility is much appreciated to improve that. As far as I understand, it is intended behaviour - #3457. |
Intended outcome:
I want to refetch data with dynamic variables.
the action flow is following:
Fetch query with variables A ==> Get result A.
Fetch the same query with variables B ==> Get result B.
Fetch the same query with variables C ==> Get result C.
Fetch the same query with variables B ==> Get result C. (<== problem is here)
Fetch the same query with variables A ==> Get result A. (??)
// result A = result B + C
my code:
Apollo Provider
query string
Component
Actual outcome:
I put two console output per action flow:
index.js(20) // link-rest response
index.js(33) // component refetch
And following is the screen shot with action flow:
Fetch query with variables A ==> Get result A.
Fetch the same query with variables B ==> Get result B.
Fetch the same query with variables C ==> Get result C.
Fetch the same query with variables B ==> Get result C. (<== problem is here)
And this is my cache screen shot:
The problem is: when I change variables, the query has sent & link-rest do receive the api data. But the react-apollo observable didn't get that new data and return the old data. Is this a bug or I do something wrong? Thank you.
Version
The text was updated successfully, but these errors were encountered: