GraphQLQuery macro creates incompatible types for fragments shared between queries

[yuyoyuppe]

trafficstars

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]

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]

@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]

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]

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

[Ten0]

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]

@tomhoule is there any progress?

[tomhoule]

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

[alokedesai]

@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]

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]

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.