You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Originally posted by benasher44 March 14, 2022
Hello! Our team has been on Apollo Client 2 for some time now, in our main frontend. This frontend is fairly large (have been QA'ing this change for months), and our goal in upgrading is to be able to use HMR available from our build tool (currently CRA but looking to migrate to Vite) — Apollo Client 3 has updates to it that make its caching friendlier for HMR.
Unfortunately, we've tried deploying this upgrade to end users 3 times without success. The first time, we ran into issues related to our own misunderstanding around how the cache-and-network cache policy changed in Apollo Client 3. In attempt 2, we were bit by #9367. In today's attempt 3, things were much more stable, but eventually we realized users were encountering issues related to #6905.
My questions are:
With Stale data on variables change with no-cache fetch policy #6905 and the related issues (in our case, we're using network-only, instead of no-cache), which issue should we be following to know when we can resume our upgrade attempt? (seems there are many that all sort of point to different ones, but all have some form of "useQuery initially gives stale data when changing variables with cache policy )
I also saw Added useQuery frame tests to show that there is an unneeded frame. #9508 (assuming I understand this PR), does this extra frame refer to the single extra render that includes stale data that's mentioned in these related issues? If so, I see that this PR refers to a possible future fix as more of an optimization. To us, this appears to be the final bug preventing us from getting to Apollo Client 3. Does the Apollo Client JS team plan to address it, or is it more of a "nice to have" thing? (linked PR seems not relevant)
Thanks for your help! Understanding where things are will help us plan our own next steps to advance our Apollo/GraphQL usage, internally.
The text was updated successfully, but these errors were encountered:
@benjamn as requested, moved this to an issue. Do you all need another repro case, or is the one in #6905 sufficient (only difference being we use network-only as the cache policy)?
Discussed in https://github.com/apollographql/apollo-client/discussions/9521
Originally posted by benasher44 March 14, 2022
Hello! Our team has been on Apollo Client 2 for some time now, in our main frontend. This frontend is fairly large (have been QA'ing this change for months), and our goal in upgrading is to be able to use HMR available from our build tool (currently CRA but looking to migrate to Vite) — Apollo Client 3 has updates to it that make its caching friendlier for HMR.
Unfortunately, we've tried deploying this upgrade to end users 3 times without success. The first time, we ran into issues related to our own misunderstanding around how the
cache-and-network
cache policy changed in Apollo Client 3. In attempt 2, we were bit by #9367. In today's attempt 3, things were much more stable, but eventually we realized users were encountering issues related to #6905.My questions are:
network-only
, instead ofno-cache
), which issue should we be following to know when we can resume our upgrade attempt? (seems there are many that all sort of point to different ones, but all have some form of "useQuery initially gives stale data when changing variables with cache policy )I also saw Added useQuery frame tests to show that there is an unneeded frame. #9508 (assuming I understand this PR), does this extra frame refer to the single extra render that includes stale data that's mentioned in these related issues? If so, I see that this PR refers to a possible future fix as more of an optimization. To us, this appears to be the final bug preventing us from getting to Apollo Client 3. Does the Apollo Client JS team plan to address it, or is it more of a "nice to have" thing?(linked PR seems not relevant)Thanks for your help! Understanding where things are will help us plan our own next steps to advance our Apollo/GraphQL usage, internally.
The text was updated successfully, but these errors were encountered: