React-apollo: Why can mutate function of MutationTuple resolve to void?

Created on 7 Aug 2019  Â·  9Comments  Â·  Source: apollographql/react-apollo

According to the typing, calling the first argument of MutationTuple returns a promise that resolves to either void or ExecutionResult. What is the reason that it can resolve to void? If there is an error in the promise it will be rejected, so in which scenario would the result be void?

It seems a bit redundant that you have to check for the existence of the result after calling the mutate function.

âš  Type error property 'data' does not exist on void | ExecutionResult

const { data } = await createPost({variables: { input }});

✅ Works, but feels weird.

const response = await createPost({ variables: { input }});
if (!response) throw new Error();
const data = response.data;

Version
react-apollo": "^3.0.0"
react-apollo-hooks": "^0.4.4"

bug confirmed

Most helpful comment

We'll definitely get this fixed (🤞in the next couple of hours). Thanks all!

All 9 comments

Agreed, this is odd. I'd suggest that function with a return type that is a union of void and _anything_ is contradictory. void means "this function doesn't really have any return value". It doesn't make much sense to say "this function doesn't have any return value, or, it has a return value".

I was facing the same issue today. Would be nice to remove that void type.
Quick fix for me was to type the mutation result to ExecutionResult, see example:

import { useMutation, ExecutionResult } from 'react-apollo'

interface IResponseData {...}

const [createPost] = useMutation<IResponseData>(createPostMutation)

const { data } = (await createPost(variables)) as ExecutionResult<IResponseData>

This prevents TS users from doing destructuring. Please remove the void.

Yeah, this is really odd and makes hooks effectively unusable, as both destructuring and use of idx don't work.

We'll definitely get this fixed (🤞in the next couple of hours). Thanks all!

I should have this fix published today (just squeezing in a few more bug fixes).

@hwillson can we get it published now? Just in case you didn't know in most node.js semver implementations you can have as many patch numbers as Number.MAX_SAFE_INTEGER so that should give you guys enough headroom to just publish a few patches every day :dancing_men: :dancing_women:

Haha @capaj! Sorry, I was pulled into an emergency for a bit, but things are getting back to normal. Publishing momentarily - thanks!

@hwillson now this is the kind of customer service that makes me lobby my organizsation into paying for the pro version of apollo-engine.

Was this page helpful?
0 / 5 - 0 ratings