Shouldn't a mutation's "then" data always be defined ?

[strblr]

Hello, when using a mutation callback, for example :

const [result, addTodo] = useMutation(AddTodoDocument);

addTodo({ content: 'test' }).then(({ data }) => someStuff(data));

shouldn't data always be defined ? (right now this is not the case in the type definition)

[JoviDeCroock]

No, because your mutation can also error out. This could mean that there’s no data coming back, in general when performing mutations it’s best to check whether or not there was an error and notify the user if so, when there’s data you can decide to continue and perform the func you want.

[strblr]

Okay! Any reason for why you didn't use catch in case of an error?

[kitten]

There are three different conditions for errors as stated here: https://formidable.com/open-source/urql/docs/basics/errors/

• network error (no data at all)
• GraphQLError(s) without data
• GraphQLError(s) with partial data

Given that we have to make a decision of when to throw, and we made one to never throw. The reason for not rejecting is two fold:

First of all, we could reject on network errors but that'd be arbitrary if you as a user would still have to check for the other kinds of errors. Also this difference isn't reflected in the combined CombinedError structure further complicating things. Throwing on potential partial data doesn't make sense, but checking data is also arbitrary.

Also, there is no catastrophic error abstraction in our exchange streamed structure. That means that we can just map results over to promises from streams (which basically don't reject / error).

Hence the easiest solution here in terms of usability is just to never reject; or to never have any error conditions that are bailing, for streams and promises.

[strblr]

Awesome, thank you for your time.