Fix extra useQuery result frames

[benjamn]

This PR builds on #9508, fixing the unexpected frame by transitioning to a loading: true result synchronously when variables change or the query is refetched.

Since we do not want to commit to making any network requests synchronously during rendering, I have come up with a new way to block all network requests, by passing a fetchBlockingPromise: Promise<boolean> option that intercepts a part of the request pipeline that is already safely asynchronous.

As a happy side effect, this fetchBlockingPromise technique should also prevent making any network requests for extra ObservableQuery objects created during development when using React's <StrictMode>, since the extra component renders are never mounted, and thus useEffect never fires, leaving the fetchBlockingPromise unresolved until it times out and the fetch gets silently canceled (as desired).

[dylanwulf]

I have confirmed that this fixes #9549 and it might also fix #9145 and #9580

[brainkim]

I think this could be merged for the sake of the release candidate but we should definitely loop around on the fetchBlockingPromise API because it is technically public.

A surgical strike by @benjamn.

cc @hwillson @jpvajda

[yusufumac]

@benjamn I came across to bug using fetchMore function which is indirectly caused by fetchBlockingPromise. Because resultsFromLink (source) can't execute query - by your design-, fetchQuery function returns undefined in fetchMore causes exception here.

[benjamn]

@yusufumac Thank you! Would you mind opening a new issue, ideally with a small reproduction? I have some guesses about what the problem might be, but it would be great to see some concrete code.

Are you saying resultsFromLink remains permanently blocked when you use fetchMore? Is it possible the component in question is never actually mounted? I ask because <React.StrictMode> generates double renderings and discards half of them without running useEffect callbacks, which could potentially be a source of components that never mount, so their fetchBlockingPromises resolve to false and stay that way permanently (or until fetchBlockingPromise is removed from the options).

Does any of that sound familiar/plausible from your debugging?

[benjamn]

@yusufumac An update relevant to your concerns: PR #9636 removes the fetchBlockingPromise logic, and was just released in @apollo/client@3.6.1 (still tagged as next rather than latest on npm for now). Please let us know if you have a chance to try npm i @apollo/client@next in your reproduction!

[yusufumac]

@benjamn Thanks for the update. It was a busy week, so I couldn't create a reproducible case for you. I downgraded to 3.5.10 and didn't have the same issue. I will try 3.6.1 and will let you know if the issue still there.