Affordance for suppressing transient transport errors

[timbotnik]

When the network has occasional drop-outs, we might not care. It would be nice for Apollo client to be able to distinguish between transport and application errors so we could do some automatic retrying and error suppression. This is especially true of polling queries.

In the case of react-apollo, when we receive new props with an error, our data can disappear. The work-around is to do something like this:

shouldComponentUpdate(nextProps) {
    if (nextProps.data.errors) {
      return false;
    }
    return true;
},

But that seems like unnecessary boilerplate for something that is a transient network event.

[Poincare]

I guess this means that Apollo Client should distinguish between network and application errors and react-apollo should distinguish between errors that require a component update and those that do not?

[helfer]

I think the right thing to do here is:

1. Handle partial results by calling observer.next instead of observer.error and write as much data to the store as we can. Thanks to error paths we can actually do this now.
2. Don't call observer.error on network errors while polling. Instead just stay in the polling network status and keep trying.

This approach will work well if we assume that people don't want to be notified when a polling query encounters a network error. If they do want to be notified, we'll need to have an extra argument to polling queries.

[helfer]

I think this is still a great idea, but the issue is quite old already. Let's continue discussion in #1210.