graphql-flutter
graphql-flutter copied to clipboard
zino-hofmann
refetchQueries option for client.mutate
Broken out from #278
Like apollo, we should add refetchQueries array within the MutationOptions of QueryManager's mutate function. We will not add support for simple mutation names as they but only the part they don't want to deprecate it.
Right now all "safe" queries are re-resolved from the cache on mutation indiscriminately, but nothing is re-fetched from the network
@micimize I noticed that mutation ids are automatically generated which means (as you mention above) we cannot refetch queries from QueryManager by name. I'm trying to understand if this was an intentional design decision, but the link in your comment above, which I presume is to a discussion of deprecating named queryIds in Apollo, returns a 404.
I'm currently trying to call refetchQuery from the QueryManager directly from a store (not triggered by UI). Is there any other way to get the appropriate query id?
I should note that I was just trying to use QueryManager.refetchQuery as an interim solution, but #278 is a better solution for my use case. However, I presume there are other reasonable use cases for refetching queries directly from QueryManager.
The dead link was about how apollo wanted to deprecate some aspect of their api. It would make sense to have an api for getting the most recent instance of a query for a given doc + variables, I'm not sure how you could do that right now
What if we just store queries as a Map<QueryOptions, ObservableQuery> instead of Map<String, ObservableQuery>?
Then in refetchQuery you would simply pass a QueryOptions object instead of a queryId String.
The deep comparison logic already exists, but we may need to adjust it to use for a base QueryOptions class
@smkhalsa we still want to maintain unique ids, because the lifecycles of two distinct operations with the same docs + variables will be different.
We can just find the relevant ids and refetch them
(used permalinks this time 😉)
