add public method to retrieve all current observable queries #7813
Conversation
benjamn
force-pushed
the
getObservableQueries
branch
from
a04f4ad to
5baa918
Compare
There was a problem hiding this comment.
After discussion with @brainkim, I was able to use the new getObservableQuery method in the implementation of client.refetchQueries, replacing the implementation-detail-heavy getQueryIdsForQueryDescriptor function.
I think this could use some more tests (especially the (see 4e022bc), though the new code is pretty well exercised by the existing "all" and "active" functionality)client.refetchQueries tests.
Over to @brainkim for the final review.
benjamn
force-pushed
the
getObservableQueries
branch
from
366eea9 to
4e022bc
Compare
|
@dannycochran If the additional commits I pushed are working correctly, the only visible change compared to your original PR is that you can now pass an argument to client.getObservableQueries("active") // default behavior
client.getObservableQueries("all") // include inactive queries too
client.getObservableQueries(["QueryName", QUERY_DOC, ...]) // also works!That one small API change makes Please let me/us know if you have any thoughts/questions/reservations. We should be able to include this PR in the next RC release for you to try. |
| public getObservableQueries( | ||
| include: RefetchQueriesInclude = "active", | ||
| ): Map<string, ObservableQuery<any>> { | ||
| return this.queryManager.getObservableQueries(include); | ||
| } |
There was a problem hiding this comment.
By default, all "active" queries will be included, but you can pass any RefetchQueriesInclude-typed value (in other words, anything you can pass as options.include to client.refetchQueries).
src/core/QueryManager.ts
Outdated
| if (fetchPolicy === "cache-only" || | ||
| fetchPolicy === "standby" || | ||
| !oq.hasObservers()) { | ||
| // Skip inactive queries unless include === "all". | ||
| return; | ||
| } |
There was a problem hiding this comment.
@dannycochran If we want to impose further restrictions on the set of active queries (for example, that we're watching the query rather than just sending it once), I think this would be the place to do it.
benjamn
force-pushed
the
getObservableQueries
branch
from
c4089e2 to
ba92852
Compare
…eries. Queries with `fetchPolicy: cache-only` are certainly not "inactive" (you just might not want to refetch them from the network), so excluding them is a choice for the reFetchObservableQueries method to make. Note: we are currently planning to deprecate reFetchObservableQueries and remove it in Apollo Client v4, so this logic will disappear from the codebase after that. The new client.refetchQueries API provides a much more flexible way to specify which queries you want to include, including the ability to filter/skip them in arbitrary ways in the onQueryUpdated function.
Although passing one-time { query, variables } QueryOptions in the
options.include array is discouraged by the type system, it's still
allowed for the refetchQueries option for mutations, so we should make
sure to stop those temporary queries after they've been fetched.
I didn't want to complicate the client.getObservableQueries API to
return additional metadata about which queries are legacy/temporary, so
I'm using query ID strings (the keys of the getObservableQueries Map) to
convey that information.
|
@dannycochran This should be available now in |
|
After upgrading The warnings seem to be introduced in this PR. The If the query is run by the code that is being tested, e.g. export const MyComponent = () => {
useMyGraphQLQuery({})
// ...
}then the warning is eliminated. I didn't notice this mentioned in the 3.4.0 changelog, but might have missed it. Not sure what the best way to deal with a scenario like this is. We could change the implementation and eliminate the need for using Just wanted to leave this here in case someone else happens to encounter the same thing. |
Checklist:
This feature is to help create a workaround for this comment:
apollographql/apollo-feature-requests#272 (comment)
By exposing the current observable queries, consumers can look at all their "refetchQueries" for a mutation, and if any of them aren't in the result of "getObservableQueries()", they can figure out how to ensure those queries are re-fetched on subsequent mounts.
This logic was already being done by query manager for its own internal handling of "refetchQueries" logic, so we are just exposing a small piece of that here.