Async-graphql: Possible to use macro_rules to expand methods prior to #[Object] attribute macro?

Created on 27 Mar 2021  ยท  4Comments  ยท  Source: async-graphql/async-graphql

For my root-level query, I have a lot of repeated methods to expose various objects in my database externally. I use a macro_rules implementation named ent_query_fns to generate three async functions for each of the names I provide. Unfortunately, the attribute macro takes precedence over the macro_rules functions expanding, so none of the macro-generated methods get fed into your #[Object] attribute macro.

Is there any way to leverage macros to add functions to the async graphql object prior to the attribute macro being processed? Or is there another way to mark a struct as a graphql object where I could use macro_rules inside an impl first?

Screen Shot 2021-03-27 at 1 33 36 PM

Screen Shot 2021-03-27 at 1 35 56 PM

question

All 4 comments

In this case, you can only let macro_rules generate the entire Object, not a part of the resolver.
Based on my experience, mixing procedural macros and macro_rules will encounter a lot of strange things, hope it helps you. ๐Ÿ˜

I tried moving nathe object generation inside the macro thinking the same
thing, but no success :'(

Guess I'll just have to do it manually instead.

On Sun, Mar 28, 2021, 7:36 PM Sunli @.*> wrote:

In this case, you can only let macro_rules generate the entire Object,
not a part of the resolver.
Based on my experience, mixing procedural macros and macro_rules in Rust
will encounter a lot of strange things, hope it helps you. ๐Ÿ˜

โ€”
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/async-graphql/async-graphql/issues/454#issuecomment-808992611,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAS55CVCUXEI6Z5SK3HUVSTTF7DQFANCNFSM4Z5FSOVQ
.

I tried moving nathe object generation inside the macro thinking the same thing, but no success :'( Guess I'll just have to do it manually instead.
โ€ฆ
On Sun, Mar 28, 2021, 7:36 PM Sunli @.*> wrote: In this case, you can only let macro_rules generate the entire Object, not a part of the resolver. Based on my experience, mixing procedural macros and macro_rules in Rust will encounter a lot of strange things, hope it helps you. ๐Ÿ˜ โ€” You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#454 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAS55CVCUXEI6Z5SK3HUVSTTF7DQFANCNFSM4Z5FSOVQ .

I used macro_rules to implement a lot of code in the past, but I encountered some weird problems when including procedural macros, and eventually I had to implement them manually. ๐Ÿ˜‚

Okay, closing out since this is more challenge with Rust than any specific library. :)

Was this page helpful?
0 / 5 - 0 ratings