Revisit refetchQueries API

[jerelmiller]

The refetchQueries API used primarily to refetch data after a mutation is a bit unintuitive in its current form. We've had quite a few questions about this feature where people misunderstand how it works.

The key part of this API primarily misunderstood is that refetchQueries only refetches active queries, which are queries that are currently mounted on screen. Once a query has been unmounted/unsubscribed, it will no longer be refetched. This presents a lot of confusion when devs think a bug exists because they don't see the network request after the mutation.

As such, I'd like to revisit this API in future major and see what we can do to improve this to make the behavior more intuitive.

[thclark]

Honestly just better documentation on it would be the useful thing - perhaps an example showing an off-screen/unmounted and an on-screen/mounted container. Revalidate them both, but see the network request fire only for the second?

Because the behaviour as-is is technically a feature, right? Why refetch data for things that aren't shown? Or is it that unmounted queries are not marked as invalid (ie when re-mounted they're not also refetched) which would understandably cause friction (because you'd always have to refresh on remount)?

Perhaps there should be an option to refetchQueries that's like strategy=ACTIVE_ONLY|ACTIVE_LAZY|OPTIMISTIC where

• ACTIVE_ONLY refreshes data for active queries only and doesn't mark inactive queries for later refresh
• ACTIVE_LAZY refreshes data for active queries and marks inactive queries for refresh once reactivated
• OPTIMISTIC refreshes data for active and inactive queries, so that refreshed data is instantly available on reactivation of those queries (one of these things that actually has poorer performance but may appear to the user as having better performance)

I don't know enough about the fetching mechanisms to understand if a fourth option OPTIMISTIC_DELAYED makes sense (in which active queries are refreshed first, then inactive queries get refreshed) - perhaps this could offer a performance advantage over OPTIMISTIC if a lot of large-but-inactive queries exist?