Strip InputValue from from_input for GraphQL scalars

[tyranron]

Synopsis

At the moment, defining a GraphQL scalar requires a from_input() function, which accepts InputValue as its argument:

#[derive(GraphQLScalar)]
#[graphql(parse_token(String, i32))]
pub struct ID(String);

impl ID {
    fn to_output<S: ScalarValue>(&self) -> Value<S> {
        Value::scalar(self.0.clone())
    }

    fn from_input<S: ScalarValue>(v: &InputValue<S>) -> Result<Self, String> {
    //                                ^^^^^^^^^^^^^ redundant, we need only `S`
        v.as_string_value()
            .map(str::to_owned)
            .or_else(|| v.as_int_value().as_ref().map(ToString::to_string))
            .map(Self)
            .ok_or_else(|| format!("Expected `String` or `Int`, found: {v}"))
    }
}

However, the only viable option to parse a GraphQLScalar is only from InputValue::Scalar variant. Machinery never passes to this function an InputValue::Enum or other variants. Thus, all the GraphQLScalar declarations use InputValue::as_string_value() or similar methods, which inside use the InputValue::as_scalar_value() method which tries to unwrap an InputValue::Scalar.

It's quite redundant to deal with the whole InputValue in from_input() functions, while the only viable and used variant is always InputValue::Scalar.

Solution

Instead, it makes sense to pass into the from_input() the already unwrapped InputValue::Scalar as ScalarValue, so the user code could deal with it directly without a need to involve any InputValue functionality.

#[derive(GraphQLScalar)]
#[graphql(parse_token(String, i32))]
pub struct ID(String);

impl ID {
    fn to_output<S: ScalarValue>(&self) -> Value<S> {
        Value::scalar(self.0.clone())
    }

    fn from_input(v: &impl ScalarValue) -> Result<Self, String> {
    //                     ^^^^^^^^^^^ use `ScalarValue` directly
        v.as_string()
            .or_else(|| s.as_int().as_ref().map(ToString::to_string))
            .map(Self)
            .ok_or_else(|| format!("Expected `String` or `Int`, found: {v}"))
    }
}

And yet, we can take a step further and provide an input/output type polymorphism for the from_input() function:

#[derive(GraphQLScalar)]
#[graphql(parse_token(String, i32))]
pub struct ID(String);

impl ID {
    fn to_output<S: ScalarValue>(&self) -> Value<S> {
        Value::scalar(self.0.clone())
    }

    fn from_input(v: &str) -> Self { // result could be infallible
    //               ^^^^ use `&str` directly
        Self(s.into())
    }
}

This is achieved by revamping the ScalarValue trait and introducing input type polymorphism via helper TryScalarValueTo conversion trait. We cannot use just TryFrom or TryInto trait for this purpose, because the conversions are made from a reference, and thus, we cannot specify the required conversions as super-trait bounds for the ScalarValue trait (which we need to make them implied in macro expansions or whenever ScalarValue is used).

The only downside, that Rust cannot infer types if the generic is specified directly, and thus, when we need to use a generic in from_input() function, we should use the transparent Scalar wrapper to aid the inference:

#[derive(GraphQLScalar)]
#[graphql(parse_token(String, i32))]
pub struct ID(String);

impl ID {
    fn to_output<S: ScalarValue>(&self) -> Value<S> {
        Value::scalar(self.0.clone())
    }

    fn from_input(v: &Scalar<impl ScalarValue>) -> Result<Self, String> {
    //                ^^^^^^ required to aid type inference
        v.try_to_string()
            .or_else(|| s.try_to_int().as_ref().map(ToString::to_string))
            .map(Self)
            .ok_or_else(|| format!("Expected `String` or `Int`, found: {v}"))
    }
}

Into-Result output type polymorphism is achieved by ::juniper::macros::helper::ToResultCall autoref-based specialization for the provided function.

Checklist

• Documentation is updated (Book and API docs)
• CHANGELOG entry is added
• Tests are updated