Successful responses with null data are rejected as errors #28

New issue

Closed

opened 2020-10-06 17:42:59 +08:00 by pimterry · 1 comment

pimterry commented

2020-10-06 17:42:59 +08:00

(Migrated from github.com)

That's works fine and its perfectly valid GraphQL as far as I'm aware, but this library rejects these responses, due to gucheen/fetchql@07d08bef9b/src/index.js (L192-L196)

In that code, a successful response that has no errors but which returns a { myOperation: null } result will throw undefined.

I don't think this case should throw. Even if it does, it should probably throw something clearer than undefined.

My API includes mutations that don't return any data. They're effectively requests for a low-priority async operation, and they return almost immediately with no information, by just returning `null`. That's works fine and its perfectly valid GraphQL as far as I'm aware, but this library rejects these responses, due to https://github.com/gucheen/fetchql/blob/07d08bef9b153929fdf3d8ea2d8a0e9faf3e245e/src/index.js#L192-L196 In that code, a successful response that has no errors but which returns a `{ myOperation: null }` result will throw `undefined`. I don't think this case should throw. Even if it does, it should probably throw something clearer than `undefined`.

gucheen commented

2020-10-07 09:01:17 +08:00

(Migrated from github.com)

According to GraphQL's specification, in 7.1.1 https://spec.graphql.org/June2018/#sec-Data

if the operation was a mutation, this output will be an object of the schema’s mutation root type.

It's better to return the root type of mutation. I would like to respect the specification.

According to GraphQL's specification, in 7.1.1 [https://spec.graphql.org/June2018/#sec-Data](https://spec.graphql.org/June2018/#sec-Data) ``` if the operation was a mutation, this output will be an object of the schema’s mutation root type. ``` It's better to return the root type of mutation. I would like to respect the specification.