Apollo-ios: Trying to parse Long-values, getting error: "Could not convert to String"

Created on 13 Apr 2018  路  3Comments  路  Source: apollographql/apollo-ios

Using Apollo 0.8.0.
The API I'm querying has a few values represented as Long. Since "there's no such thing" in Swift, I was expecting it to be parsed into Int64 or simply Int. However, when running the request, the query returns with a GraphQLResultError saying this:
GraphQLResultError(path: ["path", "to", "value"], underlying: Apollo.JSONDecodingError.couldNotConvert(value: 123, to: Swift.String))
It looks like it attempts to parse the Long-value as a String instead of an Int or any other number.
This seems quite severe to me, but I'm pretty new to the entire GraphQL-thing. Is Long not supposed to be a value? Could it be that the creators of this service has injected some values for their own purpose?
If this is the case, is there any way for me to add certain "exceptions" or "improvements" on my own?

Most helpful comment

For anyone coming across this the flag is now --passthroughCustomScalars 馃槃

All 3 comments

Long is what is known as a custom scalar, there is no such type built-in to GraphQL. Unfortunately, GraphQL currently doesn't have a way of specifying how these custom scalars should be encoded/decoded. Without further configuration, Apollo iOS assumes String.

You can use the --passthrough-custom-scalars option to apollo-codegen to leave custom scalars as is. That means you will need to define something like typealias Long = Int64 to avoid compiler errors.

@martijnwalraven Thank you! It solved my issue. When using --passthrough-custom-scalars I also noticed I needed a few other typealiases to make it work. For example, the data contained two types for date-handling. One Date and one DateTime. Simply adding a typealias DateTime = Date solved it, though I now decode them both equally. It's not a problem for my implementation, but strictly speaking, they probably should have separate jsonValue-implementations, because they're now also encoded identically.
What's strange is that before using --passthrough-custom-scalars, I didn't have to do this with Date and DateTime, it was handled automatically.

For anyone coming across this the flag is now --passthroughCustomScalars 馃槃

Was this page helpful?
0 / 5 - 0 ratings

Related issues

maxsz picture maxsz  路  4Comments

marcoreni picture marcoreni  路  3Comments

vishal-p picture vishal-p  路  4Comments

ermik picture ermik  路  4Comments

StanislavCekunov picture StanislavCekunov  路  3Comments