There is no way to mark queries as "needs to be refetched" using the apollo client instance.

Having React’s useMutation({...update, refetchQueries, reobserve...}) is great, really, but I think it’s a big flawed that we can’t use apollo client raw instance and tell it

1. mark certain queries as invalid(That’s actually something we can do using cache.modify())
2. next time those queries are observed, refetch them or… 2.1 if they are being observed at the moment, refetch them now…

I know that we can use the useMutation and tell each mutation how to behave… But sometimes we just want to be able to tell apollo client to mark some quereies as “needs a refetch” outside the context of react and I think that we should be able to do so

Looking forward for your response, Thank you again for your great work

[omerman]

@benjamn Looks great! If I’ll think of any more feedback Ill let you know 😃

[benjamn]

@omerman I believe https://github.com/apollographql/apollo-client/pull/8000 will implement what I described above, incorporating your feedback about the optionality of the onQueryUpdated callback (defaulting to observableQuery.refetch()).

Note that this new client.refetchQueries API takes named options (updateCache, include, onQueryUpdated) rather than positional arguments, which makes it easier to mix and match the options, I think.

Unfortunately I don’t have a great answer yet for your use case of queueing up refetch requests for unmounted/hidden components, but that’s definitely something we want to support. I think it will require allowing the ObservableQuery to outlive the React component, while also keeping track of whether the component is currently mounted/visible, so we can fire pending refetches when the component is remounted. That kind of functionality (keeping the query alive when the component is unmounted) makes sense for lots of reasons, I think, but the ObservableQuery class doesn’t currently have a mode of being unmounted (as far as React is concerned) but still listening for cache updates.

I welcome any feedback you have on #8000, as it is still very much subject to change/improvement!