Support __typename introspection #192
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@jamesdabbs Thanks for the PRs! Sorry we're lagging a bit in getting to reviewing them. |
|
@jml - no worries at all! I'm in a bit of a busy patch so it'll be a week or so before I can pick up this thread anyways. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey y'all - big fan of the project. Thanks for your work on it.
I'm currently working on using this as the backend for an Apollo client, which seems to assume that all types will at least support the
__typenameintrospection field for client-side caching purposes. I've been faking it by manually adding an explicit__typenamefield to every type, but wanted to take a swing at implementing this properly and learning some of the internals and type machinery here.I added a few tests, but if there's anything else I can do to improve this PR (implementation, documentation, or otherwise) please let me know.
For what it's worth, I'd be interested in continuing to contribute to this project, and would welcome any suggestions for how best to do so. I'm going to explore what I can implement in terms of supporting http://facebook.github.io/graphql/June2018/#sec-Schema-Introspection currently, though it looks like it may require some non-trivial internal changes to support e.g. querying the fields of input objects.