Trying the new Codable support

#1

Hi @mythz ,
I noticed that you added support for Codable on the last version of the swift client.
I was just giving it a try on one of my projects, but while it generated the code correctly it doesn’t compile because it gives a lot of error.
I have cleared the cache to get the latest ServiceStack server, updated the X tool, and referenced the last swift client from Github.

All error look the same, here an excerpt of the errors, and a gist with the dto file

type 'GetAppConfig' does not conform to protocol 'IReturn'
Type 'SearchListing' does not conform to protocol 'IReturn'
Type 'AppConfigResponse' does not conform to protocol 'Decodable'

This is the file generated

ServiceStack Codable (github.com)

Let me know if you need more info

#2

I’m assuming that’s because you’re still using the older ServiceStack.Swift release, try the latest 5.0.0 major version which has been rewritten to use the new Codable support:

dependencies: [
    .package(name: "ServiceStack", 
        url: "https://github.com/ServiceStack/ServiceStack.Swift.git", 
        Version(5,0,0)..<Version(6,0,0)),
],
1 Like
#3

Ok tested a little and works greats, this is good update.
I was just wondering yesterday about codable support, now I can add mock json data and load them in memory for SwiftUI previews :smile:

1 Like
#4

Sweet, Happy to hear it, yeah was good to remove all the machinery required to make JSON DTOs work previously and use Swift’s Codable support now that its standardized and has support built-into the compiler which I’d expect to be both ubiquitous and stable going forward.

Most of the time the Swift compiler will be able to generate the default implementations for most DTOs but wont for inherited classes or for Request DTOs which self references themselves, e.g. when returning themselves with IReturn<RequestDto> in which case we’ll generate the explicit Codable implementations. Should you ever want to have explicit implementations generated for a DTO you can opt-in with the new [Synthesize] attribute.

FYI I just pushed a 5.0.1 which includes gist.cafe’s Inspect support as seen: https://gist.cafe/#project/swift

Where you can dump the DTOs in a human-readable format with:

Inspect.printDump(response)

And dump a markdown table for tabular results with:

Inspect.printDumpTable(response.results)
1 Like
#5

Yeah it is as a user is small but very useful improvement, now I don’t have to manually decode from a local json which save me a lot of time :slight_smile:

About the gist cafe it doesn’t work on my side, I get this error if I do

x new gistcafe/swift ProjectName

then swift run will output this, this error also happens on console-swift

 error: no such module 'FoundationNetworking'
import FoundationNetworking

By the way this gist.cafe thing look very nice :smile:

1 Like
#6

Ok it’s because it’s only available on Linux (gist.cafe is running in an Ubuntu Linux Docker image), should be able to support Linux/macOS with:

#if canImport(FoundationNetworking)
    import FoundationNetworking
#endif
1 Like
#7

Ok good didn’t know about that :slight_smile: works fine with the condition

1 Like
#8

Hi can you also publish the last version on CocoaPods? i have a few projects still running on Pods :slight_smile:

#9

Yeah thought I did publish to CocoaPods but tried to again and looked like my login session had expired, it should be up there now.

On a side note: I had to abandon Carthage for managing ServiceStack.Swift’s PromiseKit dependency which didn’t properly support Xcode 12, only way I could get the project to build was to convert ServiceStack.Swift into a pure Swift Package Manager project. Anyway if you have issues using Carthage with Xcode 12 I recommend abandoning it and starting from a new Swift Package Manager project.

1 Like
#10

Good thanks.
Yeah i’m still using cocoapods only, in a few project for two reasons:

  1. A few deps still don’t have swiftpm
  2. Because i noticed that every time in a project i add or convert to SwiftPM, Xcode start behaving badly with intellisense it stop working multiple times in a day and a general slow down of the ide :frowning:
#11

Just noticed a little issue, when the swift dtos get generated, I get wrong name casing for the property named description.
For example this c# dto

public class FullListing
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public string Description { get; set; }
        public string CategoryName { get; set; }
        public string FullAddress {get; set;}
        public string PictureUrl { get; set; }
        public string Phone { get; set; }
        public string MobilePhone { get; set; }

        public string Email { get; set; }
    }

get generated on swift side as

public class FullListing : Codable
{
    public var id:Int?
    public var name:String?
    public var Description:String?
    public var categoryName:String?
    public var fullAddress:String?
    public var pictureUrl:String?
    public var phone:String?
    public var mobilePhone:String?
    public var email:String?

    required public init(){}
}

Because of this description field is not deserialized but all other fields are fine.

#12

It needs to use a different property name because it can’t override NSObject’s description computed property.

There’s not an easy solution other than synthesizing the whole DTO and overriding the coding keys. Unless we can customize JSONDecoder to ignore casing, i’ll see if there is.

#13

Uhm I see, I can rename it no problem, it’s still in the development phase.

#14

I was able to add support for this by modifying the keyDecodingStrategy, this change is now available from ServiceStack.Swift v5.0.2.

1 Like