update fails if a query has not yet been executed

[janaleible]

Not sure if this is a bug or intended behaviour, however, it doesn't work for my use case. The same thing has been reported (and fixed) for refetchQueries (see #690), although I do realise that this case is different.

Intended outcome:
I'm executing a mutation query which afterwards requires a manual update of the store. However, I cannot guarantee that the query I want to update has been run with the exact parameters already. If the query has not yet been executed I don't care about the update, since the result must be fetched from the server anyway.

(A simple example to illustrate the issue: consider a simple to do app. The user can view pending tasks and completed tasks. Also, the user can mark a pending task as done. The main view only shows (and queries for) pending tasks, since always loading the large number of completed tasks would impact performace. If the user marks a pending task as done, the query for completed tasks should be updated, but may not have been executed before.)

Actual outcome:
I'm using update to manually update the store. If the query I want to update has not yet been run, proxy.readQuery() will throw an error.
For my use case it would be better to return null, so that I can decide myself what to do in this case (which would be to just do nothing). I realise I could achieve this with try/catch, but this feels wrong.

How to reproduce the issue:
Execute a mutation query with an update method, which tries to read a query from the store that has not yet been executed (using the DataProxy's readQuery() method).

Version

• apollo-client@1.7.0

[stale]

This issue has been automatically marked as stale becuase it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions to Apollo Client!

[janaleible]

The issue still exists -- see also #2024

[Zoe7]

I'm running into the same exact use case and having proxy.readQuery() return null would make a lot of sense.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions to Apollo Client!

[jbaxleyiii]

hmm, I'm not sure about this. null would likely denote that the query had no data (such as when an errors array is returned) versus not existing yet which currently throws.

I'd love to hear some thoughts on this and will add this to the post 2.0 milestone to at least improve the docs on this, or actually make a change

[janaleible]

There could still be a clear distinction between null and {"data": []}, with the latter indicating no data (optionally with an errors property, just like a real query), the former indicating that the query has not yet been executed.

[Cito]

I agree that something needs to be done here. The example code in the docs at http://dev.apollodata.com/react/cache-updates.html is problematic because it does not catch the error in the case when the updated query has not yet been executed. We would need to add a catch clause to every such update which results in too much boilerplate for writing update code.

[janaleible]

Also, it feels wrong to manage control flow through try/catch in this way -- a query that hasn't been executed yet is not necessarily an exception, it may well be a valid use case.
An alternative would be to offer a method returning a boolean indicating whether the query has already been executed that could then be used with an if block.

[huv1k]

Yea, i would like some solution too, because try/catch its not ideal at all if you use some-kind of logs for errors (sentry etc.).

[filipenevola]

Hello, any updates here? Are you accepting PR on that? What is the desired solution? Return null?

Looks like a simple change here will fix the problem

apollo-client/packages/apollo-cache-inmemory/src/inMemoryCache.ts

Line 76 in 3cc1967

if (query.rootId && this.data.get(query.rootId) === undefined) {

This condition is inside read

apollo-client/packages/apollo-cache-inmemory/src/inMemoryCache.ts

Lines 75 to 89 in 3cc1967

	public read<T>(query: Cache.ReadOptions): T | null {
	if (query.rootId && this.data.get(query.rootId) === undefined) {
	return null;
	}
	return readQueryFromStore({
	store: this.config.storeFactory(this.extract(query.optimistic)),
	query: this.transformDocument(query.query),
	variables: query.variables,
	rootId: query.rootId,
	fragmentMatcherFunction: this.config.fragmentMatcher.match,
	previousResult: query.previousResult,
	config: this.config,
	});
	}

cc @jbaxleyiii

[tsvetann]

The same problem exists in "apollo-client": "2.0.4"

The only decent workaround I found is using apollo-link-state and predefining defaults for the said query otherwise it just throws which is not ideal.

[MaxDesiatov]

any updates on this?

[javierfernandes]

any update ?

Same happening with apollo-client: 2.3.0 ?
It is really annoying having to catch and parse the error message, just to make sure we are not catching any other error :(

Here is the error that I'm getting. I'm manually calling client.readQuery({ ... }).

readFromStore.js:42 Uncaught (in promise) Error: Can't find field changeSets({"project":"wd301"}) on object (ROOT_QUERY) {
  "myProjects": []
}.
    at readStoreResolver (readFromStore.js:42)
    at executeField (graphql.js:70)
    at graphql.js:27
    at Array.forEach (<anonymous>)
    at executeSelectionSet (graphql.js:22)
    at Object.graphql [as default] (graphql.js:17)
    at diffQueryAgainstStore (readFromStore.js:74)
    at Object.readQueryFromStore (readFromStore.js:16)
    at InMemoryCache.read (inMemoryCache.js:75)
    at InMemoryCache.readQuery (inMemoryCache.js:170)
    at ApolloClient.readQuery (ApolloClient.js:179)

[hwillson]

To help provide a more clear separation between feature requests / discussions and bugs, and to help clean up the feature request / discussion backlog, Apollo Client feature requests / discussions are now being managed under the https://github.com/apollographql/apollo-feature-requests repository.

Migrated to: apollographql/apollo-feature-requests#1