Scalars should not be encoded as json in mutations

[prange]

Custom scalars cannot be encoded as json objects or arrays when passed inline in a mutation. The effect is that we cannot mutate objects with such scalar fields using elm-graphql.

From Slack [@dillonkearns]:

Alright, I was able to reproduce the problem with the reference GraphQL server (graphql-js). I set up a server from the starting point here: https://graphql.org/graphql-js/running-an-express-graphql-server/ Then I added a scalar Name, and tried passing {"first": "John", "last": "Doe"} in as a Name argument. It gives a GraphQL syntax

error:
{
  "errors": [
    {
      "message": "Syntax Error: Expected Name, found String \"first\".",
      "locations": [
        {
          "line": 2,
          "column": 16
        }
      ]
    }
  ]
}

[prange]

One suggestion from the hip is that the encoders could produce the same Type that is used as the "AST" for serializing the mutation (Is it RawField?)

[dillonkearns]

Thanks for opening the issue @prange!

There is indeed an internal module for encoding data with GraphQL syntax: https://package.elm-lang.org/packages/dillonkearns/elm-graphql/latest/Graphql-Internal-Encode.

That said, there are a couple of reasons that I'm leaning more towards using JSON encoding as it is done now and then post-processing that JSON to turn it into GraphQL syntax.

1. It would be a non-breaking API change that way
2. Users could use whatever existing tools and libraries they rely on for creating Json.Encode.Values
3. The smaller subset of GraphQL syntax you can create with JSON is probably a good thing, because for example sending an Enum here could cause problems like referencing a non-existent Enum

So since conceptually what we're really doing is embedding a JSON value into a GraphQL, I think it will better reflect those semantics if transform the JSON snippet into GraphQL syntax as a post-processing step.

[prange]

Agreed, and the post-processing is probably very simple.