I'm not sure if this repository or the tooling repository would be more appropriate for a discussion about this, but I've had a look in both for mentions of Swift 4's Codable protocols, and was surprised to not see any discussions in either repository about it.
I was wondering if it would make sense to have code generated that yields Decodable Swift structs. Even better, fully Codable ones.
This would greatly clean up the generated template code for objects, and would potentially save some space by not needing to insert values into a resultMap dictionary, and then force-cast those back to the right type.
I'm fairly new to using Apollo and GraphQL and maybe that means I'm missing something obvious that would prevents this, but at the very least, discussing here will also help developers searching for this issue.
Basically, swift 4 supporting codable and coding keys completely removed the value of graphql imo.
@GiantBlue76 interested to hear your thoughts as to why? GraphQL still condenses API requests into one endpoint + a schema which is why I find it useful, but ymmv of course. Codable support would clean up a fairly hairy part of Apollo (in Swift) from what I can tell.
Indeed would be very useful. Would relieve us from converting into custom Decodable types to store these objects in a cache, for instance.
Yes I would way prefer to do things this way as it would eliminate huge swaths of errors, but it's going to require some significant refactoring. No ETA but definitely looking into getting it done sooner rather than later.
Hey speaking of Codable. I wanted to ask if there was an easy way to get a scalar of type json array to work. I have used --passthroughCustomScalars but when I got to typealias, nothing works!
@aroraenterprise I believe if you typealias to [String: Any?] that should work.
First off, thank you for such a quick response! @designatednerd
If I do the [String: Any?]
Failure! Error: GraphQLResultError(path: slide_deck.0.slides, underlying: Apollo.JSONDecodingError.couldNotConvert(value: <__NSArrayI 0x600001763c40>(
{
"background_image_key" = "slides/c5f16f40-70c1-4cfe-a76b-60692fe2b0c7/9410efbc-900a-424d-949b-e37035f71f11/Screen Shot 2019-07-19 at 12.55.00 AM.png";
},
{
"background_image_key" = "slides/c5f16f40-70c1-4cfe-a76b-60692fe2b0c7/3a4ed336-ae87-411d-9321-28e9e4a0afa0/Screen Shot 2020-04-26 at 5.50.41 PM.png";
},...
)
, to: Swift.Dictionary<Swift.String, Swift.Optional<Any>>))
Looks like maybe your outer layer is an array? You might need to do [[String: Any?]].
If that doesn't work, please email me your generated swift code and the JSON you're getting from your server to ellen at apollographql dot com, I'll see what i can figure out.
Is there a plan of implementation? I'd be happy to take a stab at this @designatednerd 馃檪
Yes, it's already in progress it's just hit a couple roadblocks, hoping to get back to it next week!
Is there a PR/branch that I can take a look at? I'm interested in seeing it under the hood. Also lmk if there's any way I could help 馃憪
At the moment, no PRs - if you take a look in the ApolloCodegenLib and the corresponding tests, there's stuff already merged for input objects and enums. Going to be taking a crack at fragments next, which is going to be the vast majority of the work.
Are there any estimates on how long this might take to be implemented?
I mean, there _are_ estimates, it's just that every single one I've had has been comically wrong. 馃檭
That said, while new codegen has been been stop and go for some time, we're hoping to get rolling in a more permanent fashion shortly. I will update this when there's an alpha to try out.
Most helpful comment
Yes I would way prefer to do things this way as it would eliminate huge swaths of errors, but it's going to require some significant refactoring. No ETA but definitely looking into getting it done sooner rather than later.