Don't strip data away from the component when the query errors

[StevePotter]

Motivation: in our UI, we want to display an error screen when a query fails (typically because of connectivity loss). But we want the user to also see the cached data. The current version does not include any cached data when there is an error. This PR fixes that.

Old behavior: if there was an error, don't include any data with the query results
New behavior: if there was an error, include data from the previous successful request

In fact, this was done about 6 months ago by @rricard but then somehow removed: #98

[apollo-cla]

@StevePotter: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

[kenleezle]

@rricard @jbaxleyiii what are you doing for your use case these days since master no longer supports this? are you using an old version? a forked version?

[calebmer]

Was #98 really the PR which removed this functionality? It appears to be trying to add the same functionality as this PR. Could you identify the exact commit which removes your desired behavior?

[StevePotter]

@calebmer hi, sorry if I wasn't more clear, but #98 added the same functionality as this PR. It just disappeared during a refactoring at some point. I never bothered tracking down where it was removed, since my concern is re-enabling it.

@calebmer do you know if there is another way to essentially say "Apollo, give me the latest query data. But if there is an error, give me any cached data along with the error." Maybe I'm missing something but this seems like a very typical use case and I don't see options to use it or mention of it in the docs.

[calebmer]

@StevePotter nope there is no way to do that. However, as of 0.10.0 if you get an error event from your observer you can call client.readQuery to get what data is in the cache. In the future we think we will not error on GraphQL errors, and instead return them with any partial data we got back from the server.

Let’s wait for a response from @rricard or @jbaxleyiii on this. I’m also going to cc @stubailo and @helfer because they may know something.