Allow Different for Strategies to encode the names of Fields, Types, Arguments, Enum Values, etc.

[Evertt]

So I was just looking at your movie database demo repo and I saw this line. And I thought, a lot of lines could've been saved there if you could just use Foundation's JSONEncoder.KeyEncodingStrategy to configure the root GraphQLSchema object with.

Okay I guess it feels a bit awkward to literally use the one from JSONEncoder, because that creates this awkward link between GraphZahl and JSONEncoder, but it would be easy enough to make your own.

enum HelloWorld: GraphQLSchema {
    static let keyCodingStrategy: GraphQLKeyCodingStrategy = .convertToSnakeCase
    typealias ViewerContext = Void

    class Query: QueryType {
        func greetMe(name: String) -> String {
            return "Hello, \(name)"
        }

        required init(viewerContext: ViewerContext) { }
    }

    typealias Mutation = None
}

So in this case the function greetMe would be represented to the outside world as greet_me. And then this strategy would obviously apply to every underlying GraphQLObject as well. So then you wouldn't need to write this code anymore:

// MARK: - MovieBase
class Movie: Decodable, GraphQLObject {
    private enum CodingKeys: String, CodingKey {
        case poster = "poster_path"
        case isAdult = "adult"
        case overview
        case releaseDate = "release_date"
        case id
        case originalTitle = "original_title"
        case originalLanguage = "original_language"
        case title
        case backdrop = "backdrop_path"
        case popularityIndex = "popularity"
        case numberOfRatings = "vote_count"
        case isVideo = "video"
        case rating = "vote_average"
    }

Because the CodingKeys would be auto-synthesized by the compiler anyway and the output representation would be decided by the static let codingKeyStrategy defined on the root GraphQLSchema.

[nerdsupremacist]

I like this key encoding strategy idea! It's probably a good option to give users of our API the option to change how the names of their fields and types work.

This is great!

In the case of Movie the CodingKeys have nothing to do with GraphZahl. Since tmdb is just a wrapper of a REST API those are the keys for decoding the values from the REST API. So those keys are just to decode from the response of the REST API and I really wanted to rename some things.

GraphZahl doesn't rely on Codable or CodingKeys at all. This was a decision I made to keep it as extensible as possible. So that a wrapper like tmdb could read the values from an API and still return them in whatever format was better for GraphQL.

[nerdsupremacist]

We probably need this for:

• Fields
• Arguments
• Enum Cases

[Evertt]

GraphZahl doesn't rely on Codable or CodingKeys at all.

Oh really? Funny, I just assumed it was all based on that.

Still happy that my idea appeals to you. ^_^