GraphQLAPI generates incorrect init

[plflanagan]

Since directives aren't working, we are doing a work-around where we need to map the return from one fragment to another -- in essence, an offer fragment, and another offer fragment with a few fields missing.

To do the conversion, I wanted to use the init on the offer fragment to map the other fragment into it, but I noticed an issue. The initial values are stored in a dictionary with keys in snake case (i.e., "large_url"), but the init stores values in the dictionary with keys in camel case (i.e., "largeUrl").

Field("large_url", type: .scalar(String.self)),

public init(...largeUrl: String? = nil...)
self.init(snapshot..."largeUrl": largeUrl...

[martijnwalraven]

I'm not sure what you mean by initial values, but values in snapshot are always stored as camel case, matching the property names.

Did you know you can convert any fragment into any other fragment (as long as it has a value for all the fields) by using a simple constructor? So if you have a fragment, you can use that to construct AnotherFragment(fragment).

[plflanagan]

I can't use that awesome fragment trick here because some fields are missing (which I'll exclude once directives work), but I am using it elsewhere where I can. 👍

And I don't think you're correct about the snapshot values, at least we are seeing snake-case on the fragments returned from the query.

    ▿ 6 : 2 elements
      - key : "total_likes"
      ▿ value : Optional<Any>
        - some : 54

Also, the code snippets in my original post are from the GraphQLAPI and confirm this.

[martijnwalraven]

Ah, you're right! The snapshot keys are supposed to reflect the response, so snake case if that's what the schema uses.

And the initializer uses the property name, so that's definitely a bug:

      public init(name: String, mass: Double? = nil, fooBar: String) {
        self.init(snapshot: ["__typename": "Human", "name": name, "mass": mass, "fooBar": fooBar])
      }

      public var fooBar: String {
        get {
          return snapshot["foo_bar"]! as! String
        }
        set {
          snapshot.updateValue(newValue, forKey: "foo_bar")
        }
      }

[plflanagan]

👍

So will the generated API eventually have the properties also reflect the schema name? Or will you guys be fixing it differently?

And just so we have a sense for planning, do you have a rough estimate when this will be fixed... whatever that fix might be?

[martijnwalraven]

I just published a new release, should be fixed in apollo-codegen v0.16.3!

[plflanagan]

Great; thanks!