Turning off __typename consequences

[vladshcherbin]

Hey, there are a lot of issues about __typename added to data. There are use cases when you want to receive data exactly as it was asked. The advised solutions were to manually deeply remove __typename from data or to turn this off with addTypename: false.

What are the consequences of turning this off with addTypename: false, will it break cache somehow/make it slower/etc ?

[rosskevin]

Look at how objects are cached, typically the default is __typename and id but you can customize this as well as remove __typename via the options.

See https://www.apollographql.com/docs/react/features/cache-updates.html#normalization

Also, watch this for more info: https://www.youtube.com/watch?v=zWhVAN4Tg6M&feature=youtu.be&t=690

[vladshcherbin]

@rosskevin yep, I checked the store using apollo dev tools. So, if I fetch users with type User, the store will have items (typename + id):

User:1
User:33

If I turn off addTypename, this will be changed to:

ROOT_QUERY.users.1
ROOT_QUERY.users.33

So the question is, are there any cons of this? For example, bad cache performance, duplication, nested types connection problems or smth else if __typename is turned off?

[rosskevin]

The video discusses your question.

[vladshcherbin]

@rosskevin I watched it and got the idea about typename. My guess is that without typename the store will duplicate same fetched items in store which is not a good thing, am I right?

[rosskevin]

I believe (if I recall) as you have seen that it will index via query instead, so if your query differs then you will have cache misses - this is all from memory as I decided after watching that the __typename (default) approach fit me best.

[vladshcherbin]

@rosskevin seems like I'll have to use defaults too and remove __typename later. Thanks, man!

[ikatun]

If you want to avoid having to manually remove __typename from every response, you can just require this module https://www.npmjs.com/package/typename-monkey-patch somewhere near the entry point of your app.
It monkey patches graphql HOC from react-apollo so that __typename is removed before sending data to your wrapped component.

[vladshcherbin]

@ikatun hey, let's hope this feature will be somehow added in core. You can track the progress or comment here 😉

[faurehu]

@ikatun are you still doing this or are you aware of a better practice?

[pitops]

interested in an update on this

[rosskevin]

interested in an update on this

@pitops what kind of update are you interested in?

This issue discusses what it is, why it is there, links to a video, and links to a document describing what and why it exists, and how to take that process into your own hands.

[pitops]

@rosskevin I am interested if there is a better practice for this, one that the apollo-client supports or will support in the near future.

[ikatun]

We dumped the react-apollo all together and switched to using our own library which exposes apollo through mobx. The library itself filters the extraneous __typename field.

Internally, it all just comes to this function

function removeTypename(data) {
  return typeof data === 'object' ? objectKeyFilter(data, ['__typename'], true) : data;
}

and then (for example in render function/method)

const cleanData = removeTypename(dataFromApollo);

objectKeyFilter being https://www.npmjs.com/package/object-key-filter

[riginoommen]

Hi @ALL,

Please check the below thread for this issue.

https://stackoverflow.com/questions/47211778/cleaning-unwanted-fields-from-graphql-responses/51380645#51380645

Regards
Rigin Oommen