Scalars should not be encoded as json in mutations

[Atle 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
        }
      ]
    }
  ]
}

[Atle 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?)

[Dillon Kearns]

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.

[Atle Prange]

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