No way to get an underlying GraphQL error from RelayMutationTransaction's onFailure:
doIt: Function = () => {
Relay.Store.update(
new CreateMyRelayMutation(), {
onSuccess: this.onMutationSuccess,
onFailure: this.onMutationFailure,
},
);
};
onMutationSuccess: Function = (response: CreateMyMutationResponse) => {
// Do stuff.
};
onMutationFailure: Function = (transaction: RelayMutationTransaction) => {
console.log(transaction.getError().message);
};
The problem is transaction.getError() in the onFailure callback only gives me access to a Relay Error, which means I can't get at the underlying GraphQL Error:
Server request for mutation `MyComponent` failed for the following reasons:
1. Cannot get name.
createMyInput!){createMy(input:$input_0){clientMuta
^^^
GraphQL errors are likely more user friendly than the Relay errors. I think onFailure should get passed the underlying GraphQL errors somehow to let tools choose which (Relay or GraphQL) is important for their use-case.
Thanks for asking about this. Relay creates error objects with a source property that includes the original error information from the server, which can be accessed as transaction.getError().source. It's an object with all the error data returned from the server.
Ah sweet, that is exactly what I needed...guess I missed it. Thanks!
That's odd, I'm getting an object of type Response from my transaction.getError(). Any ideas on what I'm doing wrong? Running with the latest development snapshot.
@rapilabs are you using the default network layer? If yes, and the error property is not what's documented then it's a bug (and worth filing a new issue).
How would you show that message to the end user?
Components are updated only in case transaction was successful..
I was thinking about using redux for that, but.. that looks like an overkill.
(onFailure would dispatch an action, which would then in turn trigger the component update)
@mloncaric: You could use setState if you wanted to avoid involving any Redux/Flux actions.
Using transaction.getError().source ..but should be included in docs...
@somit you saved me from writing a whole custom error handler.
Most helpful comment
Using transaction.getError().source ..but should be included in docs...