update fails if a query has not yet been executed

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

[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.

[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.