The ability to collect fields from both SimpleObject and Object. about async-graphql HOT 10 CLOSED

I have found a way to implement this feature and am trying it out.

#[Object]
struct MyObj {
    a: i32,
    b: i32,
}

#[Object]
impl MyObj {
    async fn c(&self) -> i32 {
          ....
    }
}

from async-graphql.

One other solution for that would be to have a macro that would autogenerate getters for each field with ability to override somehow?

from async-graphql.

I haven't thought of a good way to generate getters automatically, the only way to do it now is use a procedural macro include SimpleObject and Object to get the information I need to generate the code, I think it's pretty ugly.

gql_obj! {

#[SimpleObject]
struct MyObj {
   a: i32,
   b: i32,
}

#[Object]
impl MyObj {
    async fn c(&self) -> i32 {
      ...
    }
}

}

from async-graphql.

Yeah, it sure is.

One other option would be to allow getting fields from both simpleObj and Obj with the ability to exclude and override I guess. Can't think of anything cleaner atm, but definitely worth investigating to avoid doing the getters thing every time.

One other thing that came to mind is the ability to switch default behaviour in terms of field inclusion/exclusion, for simple/objects. As in include all by default, but allow to optionally do exclude all and then do includes. This is not very important though if it makes the code way too complex.

from async-graphql.

I doubt this is possible in the rust language unless I create a DSL with a macro, which would make the ide's auto-complete and formatting unavailable, which is not what I want.

from async-graphql.

Right, yeah, it's an interesting problem.

I'm wondering if the macro defined on impl has access to any of the fields in the struct? The idea here is that we might not even need to support using both macros at the same time as long as we can use #[Object] and tell it to do the struct work too.

from async-graphql.

Speaking of getters: this seems like a good enough solution for those types that automatically translate to graphql and back: https://docs.rs/crate/derive-getters/0.1.0 . The rest can be ignored and implemented manually.

from async-graphql.

So it is possible to generate getters and setters, I just with I could somehow manage to mark that impl that's being generated as Object.

async-graphql might benefit from something like that, because that kinda solves this particular issue we are discussing here.

from async-graphql.

Yeah had the same Idea as well. Well you could write your own derive-getters that annotates the impl with Object but how are you going to extend that impl then? Can you have more than one impl block at a time annotated with Object? Otherwise this is kinda pointless isn’t it?

from async-graphql.

Sorry everyone, I still can't do it.

from async-graphql.