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

Macro with generator.cynic-rs.dev functionality #860

Open
djkato opened this issue Mar 10, 2024 · 7 comments
Open

Macro with generator.cynic-rs.dev functionality #860

djkato opened this issue Mar 10, 2024 · 7 comments

Comments

@djkato
Copy link

djkato commented Mar 10, 2024

Hello, I would like to ask if a macro that could do the job of https://generator.cynic-rs.dev/ could exist? And if not, then why? I'm not sure what the limits of macros are, but I always rely on that generator, and every time I change my query I have to go to the site and copy everything around. Would be more convenient for me to just keep it in rust.

@obmarg
Copy link
Owner

obmarg commented Mar 11, 2024

Hi @djkato,

This is definitely possible from a technical standpoint.

It is something I may support eventually, however it's not something I'm planning on doing in the short term.

I agree that for some cases it would be nice, but I know from experience that approach has drawbacks. Prior to writing cynic i used graphql-client which takes this approach, but I found:

  1. It's quite hard to work closely with code that's hidden behind a proc macro. You can't easily look at it and see what the types are called, what the fields are called or any other info that you might need to work with the generated code.
  2. There's no easy way to customise the generated code. If there's any part of the macro generated code you'd like to change (even something as simple as type name) there's no real way to do that. This is particularly important in cynic because the generator is far from perfect. Sometimes it creates code that's just straight up wrong, but I consider that ok since a user can just fix it themselves.

Given these drawbacks I'd rather focus time on other things first.

I think I can solve some of the pain of copy & pasting into a web UI improvements to the cynic CLI such as this issue. I've not fleshed that issue out too much, but I'm imagining you could keep *.graphql files in your code and run cynic generate whenever they change to automatically regenerate *.rs files with all the contained queries. This would allow you to use existing tooling for .graphql files, and would preserve the ability to tweak the generated rust code.

I've also been considering a cynic generator --edit command or similar that can open up the generator with the contents of a local .graphql file, so you don't need to copy & paste if you'd prefer to use the generator UI.

@djkato
Copy link
Author

djkato commented Mar 11, 2024

Oh that's an even better idea! I can see the stuff that a macro would generate to be harder to access, and a CLI regenerator would be way better.

Ideally it would also create strings of each query so I can reference them later, cuz in my current projects I have to always send that query as pure string somewhere, eg. with webhook subscriptions.

@obmarg
Copy link
Owner

obmarg commented Mar 11, 2024

Oh that's an even better idea! I can see the stuff that a macro would generate to be harder to access, and a CLI regenerator would be way better.

Yeah, it's definitely an approach I want to explore. Although I can't promise I'll get to it anytime soon.

Ideally it would also create strings of each query so I can reference them later, cuz in my current projects I have to always send that query as pure string somewhere, eg. with webhook subscriptions.

Could you explain this use case a bit more please? I can see why you might need the string query, but how that relates to webhooks I'm less clear on? Just curious to see if there's some way to improve cynic to cater to this.

@djkato
Copy link
Author

djkato commented Mar 11, 2024

Sure, tho this is probably very specific to me. I'm making Saleor apps, and the way they communicate is through webhooks, where if an event happens in Saleor, Saleor sends me back a graphql queries result, which I define in an app manifest.
https://docs.saleor.io/docs/3.x/developer/extending/apps/architecture/manifest
https://docs.saleor.io/docs/3.x/developer/extending/webhooks/subscription-webhook-payloads
I didn't really think about if I can serialize Rust structs into those subscriptions and send them like that, I am right now rewriting them from Node and since I had them declared like that there I just went with it.

@obmarg
Copy link
Owner

obmarg commented Mar 11, 2024

Ah yeah, I see. Interesting, I haven't seen that approach to webhooks before, though it makes sense.

Might be something I can do to make that easier at the moment tbh. It's definitely possible to generate the query off the structs, I'm just not sure if I've exposed enough of the internals to let a user do it.

@obmarg
Copy link
Owner

obmarg commented Aug 21, 2024

@djkato FYI I just merged #1004 which may help with your use case where you want access to the query string

@Bobrokus
Copy link
Contributor

Bobrokus commented Aug 22, 2024

I've also been considering a cynic generator --edit command or similar that can open up the generator with the contents of a local .graphql file, so you don't need to copy & paste if you'd prefer to use the generator UI.

That's a fabulous idea! Also, something like custom derive macros for all structs would be cool. E.g. derive Clone for all structs.

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

3 participants