Some queries do not come through on client

[ryannealmes]

I am trying to figure out why queries that are executed directly on the ApolloClient with .query do not appear in apollo-client-devtools. Well they do appear, but only temporarily.

When composing a graphql query on a component you get the following actions

APOLLO_QUERY_INIT
APOLLO_QUERY_RESULT

However when executing a query directly using the client (i.e. my case I am using withApollo to pass client to my component) you get the following actions

APOLLO_QUERY_INIT
APOLLO_QUERY_RESULT
APOLLO_QUERY_STOP

Queries with the latter actions seems to have their result removed from the store once retrieved. So you actually see it pop up in the devtools, but then it disappears.

Devling into the apollo-client and react-apollo it seems that composed components use

return this.queryManager.watchQuery<T>(options);

whereas withApollo uses

return this.queryManager.query<T>(options);

From my understanding query seems to remove/stop the query once it's completed. This seems to be governed by shouldSubscribe - found here. I am still not 100% sure how. The codes jumps around quite a bit. It would be great if someone could point me to some documentation or explain how ObservableQueries work in the context of the apollo-client. It seems the term subscribe is used quite a bit, but I feel like this is different from the conventional subscription people refer to in apollo. I couldn't quite link it to everything.

I am trying to get into the library so I can contribute more. Any help here would be appreciated.

In the end I would like withApollo queries to appear in the apollo-client-devtools.

Thanks.

[stubailo]

This is because the dev tools look at currently active queries, and queries run with query(...) are only active for the short moment before the server returns. I think the best solution would be to keep some limited log of "recent queries" even when they are inactive.

[tnrich]

@stubailo We definitely would love a way to see a list of unwatched queries. They are equally important as watched queries so there is no reason not to have them.

Thanks!

[stubailo]

Yeah, I think that would be more of a request log or query log, whereas the watched queries thing is more about what's active on the page. I think the query and mutation request log could be one panel, and watched queries be another panel.

[tnrich]

@stubailo I'm not sure I agree as I like the query/mutation division that currently exists. But, whatever the final solution looks like, it will be a big improvement so long as it adds the ability to review/replay unwatched queries.

Towards that end, I'm going to start hacking on a fork trying to implement this when I have some spare time.

[hwillson]

Moved to #374 - thanks!