Provide a way for hooks to pause and resume re-rendering on cache updates

[jbachhardie]

It would be incredibly helpful to have an API that allowed us to make a hook stop re-rendering the component its in when the cached data changes. I'm imagining something like:

const { data, startListening, stopListening } = useSuspenseQuery(query)

useFocusEffect(useCallback(() => {
  startListening()
  return () => stopListening()
}, [startListening, stopListening])

This is specifically because when working with React Native you usually (in common frameworks like React Navigation) keep previous screens mounted after navigating to other screens so that navigating back to them can be animated smoothly. This can really tank performance if a bunch of previous screens were all, say, requesting a field that updates frequently, since React will be processing a large amount of renders for components that are currently hidden from view.

With useQuery it was possible to achieve this effect by using observable.silentSetOptions({ fetchPolicy: 'standby' }) but now that useSuspenseQuery shares the same observable between multiple hooks setting the fetchPolicy has wider potential effects than would be intended.

[jerelmiller]

Hey @jbachhardie 👋

This is an intriguing idea!

I saw you added apollographql/apollo-client#12587. I'm curious, would fixing that issue and using queryKey in your useSuspenseQuery hook to ensure that hook creates a unique ObservableQuery instance be enough to satisfy this request? That way you could set skip while the view was in the background without affecting other hook instances due to a shared ObservableQuery.

[jbachhardie]

I saw you added apollographql/apollo-client#12587. I'm curious, would fixing that issue and using queryKey in your useSuspenseQuery hook to ensure that hook creates a unique ObservableQuery instance be enough to satisfy this request? That way you could set skip while the view was in the background without affecting other hook instances due to a shared ObservableQuery.

I think the problem there is that it's totally prohibitive to ensure that every hook has a globally unique queryKey, especially when components are re-used. On web it's chill because any given page is not super likely to render the same data multiple times but in native where every screen in a stack is rendered at once you get into this problem where if two screens are both using, say, the same <AccountDetails> widget then how do you set a distinct query key? We could do something where we automatically concatenated some sort of hash of the route name and parameters onto every query key but it's pretty finicky.

Considering that useSuspenseQuery and useRead already have a method to unsubscribe from their shared query ref when unmounted (via useEffect) I feel like we could without too much trouble just expose that somehow. Although I know that adding a new API is a big ask since it becomes another thing that has to be maintained in perpetuity.

[jerelmiller]

every hook has a globally unique queryKey

Oh I should mention that queryKey doesn't have to be globally unique, it just has to be unique within the same query and variables combination. query and variables make up part of the suspense cache key, but queryKey is an additional qualifier on top of these two values, not a replacement for them (see this line of code for reference). It just adds that additional differentiator for uniqueness that Apollo Client would otherwise not be able to figure out given these two values were equal.

You can use the component name as a queryKey, for example, just fine as long as useSuspenseQuery with the same query/vars is used across different components. The only case where this becomes problematic is if your component is used in a loop and each instance of the component in that loop uses the same variables.

I will admit though that I'm not as familiar with React Native and its view layer so I don't know that I can recommend a good value to use in this case. I don't know what you would have available to differentiate the different AccountDetails widgets across different views (assuming they are the same query/vars combo), but if you had a url-like object/string, this would work as well.

Although I know that adding a new API is a big ask since it becomes another thing that has to be maintained in perpetuity

This is the biggest reason I ask so your intuition is spot on. I think if we were to add something to useSuspenseQuery, we probably want to think about adding this feature to all (or at least most) query-based hooks so that you can opt out of rerenders when it makes sense. Likely this would make it to the core API (ObservableQuery) so that we could opt out of observable notifications and take this to all frameworks. If there is any chance to solve this issue with what we have today though, we'd prefer that. Totally understand if today's API is too limiting, hence why I'm digging deeper into this.

[phryneas]

Especially for the React Native use case, it seems that React is currently solving this on their side.

In the past, it was already possible to "freeze" background screens with some experimental workarounds, but now React is showing intent to ship the Activity api (blog post) which effectively allows to unmount off-screen components while keeping their state. That would unsubscribe them from ongoing ObservableQuery instances.

[jbachhardie]

That's a good point about the Activity API. I can see it doesn't make sense for you to ship an API to solve a problem that React themselves will solve soon. I think if we fix that skip bug we can probably have a workaround on our side until Activity ships to Native