Access Context when defaulting fields

[mwilliammyers]

Is it possible to access Context when defaulting fields for GraphQLInputObjects? (I don't believe it is...)

I think it would be really useful to support dynamic defaulting of input field values based on the current Context:

struct Context {
    /// The ID of the user making this request, obtained from a JWT.
    current_user: Id,
}

#[derive(serde::Serialize, juniper::GraphQLInputObject)]
struct MessageInput {
    #[graphql(default = "context.current_user")]
    author: Id,
    
    body: String,
}

This could either be combined with the skip attribute (from #463) or validated elsewhere to ensure that context.current_user has authorization to set the author of a Message to the provided value.

Drawbacks

• Not sure how "official" this is and would have to be documented in playground/graphiql etc...

Alternatives

• Making the field an Option and then later mutating it/creating a new struct with the default from the Context. I don't like this method because then you have to be careful about exactly when the field will become Some and what sets it.
• Using a different struct and using a custom From like trait to fill it in with the field from Context

[LegNeato]

Not sure I understand this request. This is just so you can use the derive without breaking out into the juniper::object proc macro? What is the advantage over doing something like:

#[juniper::object]
impl Message {
  fn author(&self, context: &Context) -> Id {
    context.current_user
  }
  fn body(&self, _: &Context -> String {
    // ...
  }
}

See https://graphql-rust.github.io/juniper/master/types/objects/complex_fields.html and https://graphql-rust.github.io/juniper/master/types/objects/using_contexts.html

[mwilliammyers]

Ahhh. I guess I should have been more explicit—I am proposing adding the ability to derive default values for GraphQLInputObjects with access to Context.

[davidpdrsn]

Using a different struct and using a custom From like trait to fill it in with the field from Context

IMO this approach is fine. It might also make the code easier to understand.

[mwilliammyers]

Yeah, in most cases it is easier to understand with a separate From impl; although for small and quick things (which is what I would use it for), I think it cuts down on the boiler plate and keeps things simple and clean.