Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make addTypename a default transform #616

Closed
stubailo opened this issue Sep 2, 2016 · 3 comments
Closed

Make addTypename a default transform #616

stubailo opened this issue Sep 2, 2016 · 3 comments
Milestone

Comments

@stubailo
Copy link
Contributor

stubailo commented Sep 2, 2016

Having the __typename on the client is really useful, and every spec-compliant GraphQL server is supposed to support this feature. I think we should turn on this transformation by default.

This might even let us build in features that rely on the __typename being present.

@stubailo stubailo changed the title Make addTypename the default transform Make addTypename a default transform Sep 2, 2016
@stubailo
Copy link
Contributor Author

stubailo commented Sep 6, 2016

@stubailo stubailo mentioned this issue Sep 29, 2016
@stubailo stubailo modified the milestone: New API/Refactor Sep 29, 2016
@swernerx
Copy link

swernerx commented Dec 9, 2016

@stubailo There is just one big issue with this. When we serialize the data coming with typenames by default, mutate it via some client action e.g. using redux-form, then send it back, we still have the typenames inside the data. As our queries do not contain typenames, this fails. What is the suggest approach for fixing this? Disabling "addTypename" or adding typenames to each query?

@helfer
Copy link
Contributor

helfer commented Dec 13, 2016

@swernerx if you don't use fragments, you can disable addTypename, but the easiest and most certain fix is probably to add __typename manually for the time being.

swernerx added a commit to sebastian-software/edgestack that referenced this issue Dec 22, 2016
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 17, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants