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

Support multiple operations per query document #31

Closed
tomhoule opened this issue Jun 25, 2018 · 4 comments
Closed

Support multiple operations per query document #31

tomhoule opened this issue Jun 25, 2018 · 4 comments
Milestone

Comments

@tomhoule
Copy link
Member

Probably via a struct attribute on the query struct to specify which operation it should implement.

For now we should document that we only support one operation by document (like Apollo Client, I think?)

@tomhoule tomhoule added this to the 0.1 milestone Jul 3, 2018
@tomhoule tomhoule modified the milestones: 0.1, 0.2 Jul 12, 2018
@tomhoule
Copy link
Member Author

This is important because it's the most natural way to share fragments between multiple operations (an operation is either a query, a mutation or a subscription).

@tomhoule
Copy link
Member Author

tomhoule commented Aug 1, 2018

I started implementing that - the question is whether we should keep the 1:1 match between a struct under derive and an operation, or generate multiple implementors of the GraphQLQuery trait (one for each operation).

I tend to prefer the first option, as it's more explicit and gives more control to users (and it's not a lot of boilerplate to define additional structs with nearly the same options but a different name).

@tomhoule
Copy link
Member Author

tomhoule commented Aug 1, 2018

Question: should we select the operation with the name of the struct by default, or the first one, or a combination of both? I think the struct name, with a fallback on the first one makes sense - or maybe struct name, and error if there is no match.

tomhoule added a commit that referenced this issue Aug 1, 2018
See issue #31 for a discussion of the feature.

We should document this at some point, probably not in the README or it is going to get cluttered.
@tomhoule
Copy link
Member Author

tomhoule commented Aug 4, 2018

done!

@tomhoule tomhoule closed this as completed Aug 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant