You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we have a single error type ApolloError for gathering network errors and GraphQL errors. This class provides separate properties for each: networkError and graphqlErrors respectively.
The problem
These errors are mutually exclusive. According to our docs:
The keyword here is or. Looking at our own code base, you'll see that in practice, this statement holds true.
The differences in these errors also have implications for how other parts of the library behave when an error is encountered. For example, useQueryalways calls onError for network errors regardless of the error policy. useSuspenseQuery will always throw when a network error is encountered, regardless of the error policy.
By using a single type to model 2 distinct behaviors, this leaves room for impossible states. What happens if both networkError and graphqlErrors are set? Should networkError have priority over graphqlErrors because its more unexpected than the other? These properties are meant to be mutually exclusive, so we should model it this way.
Proposal
Rather than have multiple properties on a single error type, we'd like to split ApolloError up into distinct error classes. Doing so allows us to better model the distinction between different error types.
This has positive implications for other types of the code base as well. For example, our ApolloQueryResult has 2 error properties. This invites confusion as at times its not fully clear which of these properties I as a developer should be using to determine which to look at since both can be set under certain conditions.
Because we can treat these errors as mutually exclusive, we can narrow this down to a single error property set to the proper error instance.
consterrorLink=onError((error)=>{// alternate style by checking its instance typeif(errorinstanceofApolloNetworkError){// ...}elseif(errorinstanceofApolloGraphQLError){// ...}});
The text was updated successfully, but these errors were encountered:
Currently we have a single error type
ApolloError
for gathering network errors and GraphQL errors. This class provides separate properties for each:networkError
andgraphqlErrors
respectively.The problem
These errors are mutually exclusive. According to our docs:
The keyword here is or. Looking at our own code base, you'll see that in practice, this statement holds true.
The differences in these errors also have implications for how other parts of the library behave when an error is encountered. For example,
useQuery
always callsonError
for network errors regardless of the error policy.useSuspenseQuery
will always throw when a network error is encountered, regardless of the error policy.By using a single type to model 2 distinct behaviors, this leaves room for impossible states. What happens if both
networkError
andgraphqlErrors
are set? ShouldnetworkError
have priority overgraphqlErrors
because its more unexpected than the other? These properties are meant to be mutually exclusive, so we should model it this way.Proposal
Rather than have multiple properties on a single error type, we'd like to split
ApolloError
up into distinct error classes. Doing so allows us to better model the distinction between different error types.This has positive implications for other types of the code base as well. For example, our
ApolloQueryResult
has 2 error properties. This invites confusion as at times its not fully clear which of these properties I as a developer should be using to determine which to look at since both can be set under certain conditions.Because we can treat these errors as mutually exclusive, we can narrow this down to a single
error
property set to the proper error instance.The text was updated successfully, but these errors were encountered: