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

[omerman]

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

[benjamn]

@omerman This is one of the goals of #7819 and #7827 in the next minor version of Apollo Client (v3.4). However, I should warn you that I'm still working through some issues around calling onDirty reliably/predictably, especially while optimistic updates are happening, so I don't have a complete story to tell just yet.

[omerman]

@benjamn I understand from these issues that there is work in progress regarding the abilities of the cache using the client instance, and also that you don't have the complete story.. But I couldn't quite understand how batch & reobserve settings are about to work and achieve these goals.

I have a use case where my server has implemented graphql queries, but there are no mutations implemented, all of the updates are implemented via rest api..
Assuming Im not about to refactor and use RestLink for the mutations, Will I be able to use the introduced api to tell some queries to be marked as "needs refetch" using apollo client instance alone?
And without using fetchPolicy of 'cache-and-network'
And, How will it look?

[benjamn]

@omerman I think you've convinced me that the reobserveQuery functionality should be available as a standalone ApolloClient method, apart from mutations. Then you could do something like this:

client.reobserveQueries(
  // This callback invalidates some fields in the cache.
  cache => {
    cache.modify({
      someField(value, { INVALIDATE }) {
        return INVALIDATE;
      },
    });
  },
  // This callback gets called for any ObservableQuery objects affected by the invalidation.
  (observableQuery, diff) => {
    // Force any affected queries to be refetched from the network.
    return observableQuery.refetch();
  },
);

Would that be useful to you?

[omerman]

@benjamn If I understand it correctly, it would be useful :), I have a few clarifications/questions:

1. If i use this on a query that was observed on a previous screen for example, but now it's not, meaning I used useQuery on screen A, navigated to screen B, and in screen B I no longer observe the same query.. and I invalidate the screen A query.. will it be considered "affected" as you mentioned? If so, that is exactly what Im looking for!
2. I believe the second argument of the client.reobserveQueries() should be optional, and when not given, it should by default be return observableQuery.refetch(); as you gave in your example, what do you think? Would it not be the desired outcome most of the times?
3. In the example you gave the callback used is observableQuery.refetch(), meaning affected queries will be refetched immediately, which is okay for queries that are currently being watched, but what will happen when something like the 1st case I presented happens?
   (query A in screen A is watched, and now as part of screen B I use this api to mark query A as invalidated) will it refetch query A right away? Because if so, it's not as affective as it can be.. I would expect query A to only be marked as "needs refetch" and when I try to observe it again, it will refetch.

Let me know what you think

[benjamn]

@omerman I believe #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!

[omerman]

@benjamn Looks great! If I'll think of any more feedback Ill let you know :)

[amitozalvo]

I still don't understand how can I cause a query to refetch when it's not currently active..
Before the update, client.refetchQueries would just refetch the queries i've included (even if they are not active).
INVALIDATE from the root query doesn't work either.

I'm clueless by something that should be really easy in my opinion...

[dylanwulf]

@amitozalvo There's a separate issue open for that: #7060

[bignimbus]

Thanks all - it looks like this particular issue is resolved. Per @dylanwulf's comment, let's use #7060 for further discussion 🙏🏻