Skip to content

GraphQLQuery macro creates incompatible types for fragments shared between queries #312

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

Open
yuyoyuppe opened this issue Mar 8, 2020 · 10 comments
Labels
enhancement New feature or request

Comments

@yuyoyuppe
Copy link

I'm using Github v4 API to query some repo state and have some fragments like this:

fragment PullRequestView on PullRequest {
# ...
}

fragment IssueView on Issue {
# ...
}

to later use them in multiple queries. GraphQLQuery macro currently generates a Rust module with all fragments used by a query for each query encountered, producing incompatible types with identical layout.

I'm currently using a workaround described here, but it would be nice to have an option for generating a single common type for chosen fragment.

@tomhoule
Copy link
Member

Are your fragments in the same query document (same graphql file)? I think it's a different problem if the fragments don't belong to the same document. One solution if you want to reuse fragmetns inside the same document would be an API (possible a function-like proc macro) that generates code for all the queries and fragments in a query document, in different modules. That way fragment sharing would be easily achievable.

If we want to reuse fragments between different .graphql files it's a different story, but I think there are many downsides to that that we would need to consider.

@yuyoyuppe
Copy link
Author

yuyoyuppe commented Mar 15, 2020

@tomhoule they're in the same document. I mean, if there's an option to share fragments even only for the same document, it shouldn't be difficult to restructure graphql docs to enable it from a user POV.

@tomhoule
Copy link
Member

I think we can support that quite easily - I'm getting closer to the end of my big codegen refactoring, and it will make that even easier. I'm curious, do you use the derive-based API or the CLI?

@yuyoyuppe
Copy link
Author

nice! I'm only using derive-based API, not a fan of keeping auto-generated code in a vcs.

@tomhoule tomhoule added this to the 1.0 milestone Mar 26, 2020
@Ten0
Copy link
Contributor

Ten0 commented Jun 10, 2020

Any progress on this ? Not having this makes code factoring really difficult.
If you need help I may be able to free some time to work on this, but I'd need guidance.

@xDarksome
Copy link

@tomhoule is there any progress?

@tomhoule
Copy link
Member

tomhoule commented Nov 5, 2020

No. I do not have time to work on this. But I would be happy to review a pull request.

@alokedesai
Copy link

@tomhoule Do you have any code pointers or give an overview for how this could be implemented? I'm happy to send you a PR with your guidance

@tomhoule
Copy link
Member

I haven't worked on this crate in a long time so I don't have much context left, I'd need to relearn the codebase. The pointer I gave two years ago in the message above are all I have.

@Ten0
Copy link
Contributor

Ten0 commented Mar 16, 2023

AFAIK this kind of issue is one of the main reasons why cynic exists.
I happen to be currently (precisely at the time of writing this, after a few years) rewriting the SDK for which I posted the message above with cynic , precisely because of this kind of limitation.
Overall if you find yourself needing this kind of factoring, this probably means your SDK is complex enough that you probably want to write it with cynic, and leave graphql-client (which is however easier to use) for simpler cases.

@tomhoule tomhoule removed this from the 1.0 milestone Jan 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants