At the moment, createSmartQueryOptionsFunction and createMutation"swallow" errors when you don't define an onError function (which is usually done with the codegen plugin):
|
} catch (error) { |
|
const { onError, context } = params; |
|
const errorHandlerResult: ApolloErrorHandlerResultInterface | undefined = |
|
onError != null ? onError(error, app, context) : undefined; |
I find this behavior quite unintuitive. I would expect the to return the plain error returned from the reuqests (usually an ApolloError), same as the normal vue-apollo smart query / mutation do. Especially since the errorHandleResultInterface seems very opinionated and doesn't match the standard vue-apollo behavior:
|
} catch (error) { |
|
const { onError, context } = params; |
|
const errorHandlerResult: ApolloErrorHandlerResultInterface | undefined = |
|
onError != null ? onError(error, app, context) : undefined; |
If you want to use this library mostly for the benefit of having types for operation arguments, and results, it's not necessary to conform to a different error result.
At the moment, createSmartQueryOptionsFunction and createMutation"swallow" errors when you don't define an onError function (which is usually done with the codegen plugin):
vue-apollo-smart-ops/src/mutation.ts
Lines 109 to 112 in ecf949e
I find this behavior quite unintuitive. I would expect the to return the plain error returned from the reuqests (usually an ApolloError), same as the normal vue-apollo smart query / mutation do. Especially since the errorHandleResultInterface seems very opinionated and doesn't match the standard vue-apollo behavior:
vue-apollo-smart-ops/src/mutation.ts
Lines 109 to 112 in ecf949e
If you want to use this library mostly for the benefit of having types for operation arguments, and results, it's not necessary to conform to a different error result.