Clarify how to use GraphQLValues in Arguments

[Denommus]

Currently, I'm generating a dynamic GraphQL enum from the database (hence, I need access to my Context and TypeInfo), to be used as an input argument in one of my queries.

But right now I'm manually calling resolve from within the resolve_field_async in order to see whether my argument actually is a valid value for that Enum.

That happens because args.get only uses FromInputValue, it doesn't actually call resolve. And FromInputValue doesn't have access to Context and TypeInfo.

In conclusion, it would be useful if there would be a way of resolving Arguments, not only "getting" them.

[tyranron]

@Denommus yup, this is somewhat non-symmetrical. The juniper was designed considering possible dynamic GraphQL types, but was never really used/polished for them. With landing #1072 we'll have better core traits design allowing us working towards natural support of dynamic GraphQL types. And we'll inevitably hit the issue you've raised. Maybe not a 0.16 release goal, but will be definitely on our agenda. Thank you for clarifying this.

[Denommus]

@tyranron besides manually calling resolve within resolve_field of its respective field, is there another way to check the type of an argument right now?

[tyranron]

@Denommus what do you mean by "check the type of an argument"? An argument is given as an InputValue it has no type. GraphQLValue implementor decides which type to "deserialize" it into.

[Denommus]

@tyranron I mean GraphQL Type. args.get::<Foo>("foo") does not check if the argument is a valid value as defined by the GraphQLType and GraphQLValue implementations on Foo.

[tyranron]

@Denommus whether the type matches GraphQL schema is checked in a validation layer, before doing resolve.

[Denommus]

@tyranron ah, but that validation layer doesn't check dynamic enums, is that it?

[tyranron]

@Denommus yeah, it actually reuses FromInputValue implementation in the way:
|v| T::from_input_value(&v).is_ok()

I wonder whether we can specify Context and TypeInfo there. Seems that there is nothing wrong with it, as they're already present when validation happens, except the current machinery doesn't support it.

Oh... one edge case is that default values are validated on schema creation, where no Context is present. Need to think about it more.

Also, another pain point maybe possible persisted queries in future. Where the query will be validated with one Context, but executed (resolved) with another one.