InputValue and Value Should have a nullable enum. about juniper

[mhallin]

Usually, you shouldn't have to deal with Value enums directly. Unless I'm misinterpreting something, your example seems to be creating a complex scalar object, something that's probably better to implement as an actual object since you can't make selections on scalars.

I would rather write your example as:

struct Movie {
    release_date: Option<String>,
}

graphql_object!(Movie: () |&self| {
    field release_date() -> Option<&String> { self.release_date.as_ref() }
});

[TheServerAsterisk]

Perhaps my example was a bit weak. Consider you have some GUI application that receives n CSS parameters. In order to construct a completed view, all n parameters must be queried, so in my opinion, there isn't a lot of value to being able to select the specific fields because there is no situation in this case where I wouldn't need to read all the fields in. The main advantage to doing something like this is that it reduces the body length significantly especially if n is a large number. The downside would be that there might be more processing and memory usage on the server side.

Also, as a side point, assume that you cannot serialize these parameters and save them locally on the machine (which would be a preferable solution here) in which case you serve a path to the file via graphql and then have nginx or some file server/cdn deliver the content.

To me at least sacrificing server resources for a more easily built query string is worth it. However, a nullable enum would be needed.

[mhallin]

I see.

Null values are supported - just use Value::Null. It seems like you want a convenience method like:

fn optional_value(v: Option<Value>) {
    v.unwrap_or(Value::Null)
}

Or something more generic that can take something that implements Into<Value>?

[TheServerAsterisk]

tl;dr I don't think there needs to be any alteration to the crate.

Hmmm, yeah, perhaps I was overcomplicating things. At worst case, I will have to clone some things due to the &self being enforced in the resolve function. However, generally speaking, the issue can be solved generally like so...

struct Movie  {
    release_date: OptionString> 
}

graphql_scalar!(Movie {
     description: "Describes a movie."
     resolve(&self) -> Value {
          Value::Object(self.into())
     }
    
     ....
}

// Untested
impl<'a> Into<HashMap<String, Value>> for &'a Movie  {
    fn into(self) -> HashMap<String, Value> {
        let mut object = HashMap::new(); 
        object.insert(
               self.release_date.clone().map(|x| Value::String(x))
          ).unwrap_or(Value::Null);
         return object; 
    }
}

Then again I might be able to just leverage the encode function from rustc_serialize and spit out a string that way, but I would argue it might make more sense for the end user to treat the scalar JSON object instead of a string. Alternatively, if I leveraged serde I could convert the &Movie to a serde::Value and then convert those values into the juniper values.

To be honest, I am starting to like the idea of just making the body longer and using the graphql object macro regardless of the size of n a lot more.