__typename field prevents updates

Hi,

High-level issue: appended __typename field causes errors when updating.

Details: When retrieving data for a custom address type, it appears that (by design) __typename field is added to the type e.g. I have an Address type on the server, and on the client this is fetched as shown below:

,"homeAddress":{"street":"1 John Doe St","line2":"","city":"Doe City","state":"California","zip":"91111","**__typename":"Address"**},

The UI permits changes to this address data, and then when I take this data object (generated by a watchQuery), and pass the same (user modified) object back as a mutation variable, the mutation fails with the error below.

{"errors":[{"message":"Variable \"$homeAddress\" got invalid value {\"street\":\"1 John Doe St\",\"line2\":\"\",\"city\":\"Doe City\",\"state\":\"California\",\"zip\":\"91111\",\"__typename\":\"Address\"}.\n**In field \"__typename\": Unknown field."**

As I understand it, the problem is introduced because __typename is created by the graphql server, but not considered valid when resubmitted back. Not sure if this would be considered a valid “bug” or if i just need to follow another approach.

Here are the options I can think of:

1. Disable adding typenames (I saw some hints that this was an option). I guess the main impact here would be that I can’t use fragments? If so, I could live with that.

2. Cleanse the _typename field manually on the client (ugh). Would this have the same impact – fragments won’t work.

3. Wait for a bug fix. I don’t know enough about how / why __typenames are added to know if there is a potential fix that address the update scenario I described without breaking other scenarios. If it’s considered a valid bug and fixable long-term then that would be good to know. Perhaps one option is to disable the validation that occurs on mutations to always allow the __typename field to be submitted?

4. Change my schema to explicitly add __typename as a data field for each type. Not sure if this would create unwanted side-effects. I’m thinking of this as a workaround, not necessarily a fix for root cause.

Please advise if I’ve missed anything.

Thank you,

S. Arora

p.s. i’m using apollo-angular 0.13.0 with apollo-client 1.0.2

[cdelgadob]

Well I honestly think that if GraphQL injects the “__typename” field to make caching better, it should handle it as an input, and not throwing an error and leaving that for us to handle.

It’s GraphQL internals at the end of the day.

So from my point of view, options are:

1. Filter the __typename column when Apollo receives the results, after using it in the cache and before passing it over the app. This would leave the implementation and handling up to the client, so I wouldn’t vote for it since it’s not universal.
2. The GraphQL server should accept the __typename column as an extra optional input, not included in the schema, as an internal mechanism. It can just discard it or use it for other purposes.

For the moment, I’ll strip it manually.

Happy graphql’ing! 😉

Carlos

[danderson00]

There are lots of people hitting this issue. This issue should definitely not be closed without explanation.

It is a cardinal sin for a library to modify incoming objects and expect developers to implement hacky, manual workarounds to deal with the modification.

Is there any intent for the maintainers to improve the situation?