Extensions giving Swift's Codable API type inference super powers 🦸‍♂️🦹‍♀️

Hey John 🙌,

First of all great job with Codextended 👍

This PR refactored the encode and decode API when using an DateFormatter to an protocol-oriented solution, allowing to pass any kind of EncodeTransformable or DecodeTransformable implementation in order to transform / convert / manipulate the value.

public typealias Transformable = EncodeTransformable & DecodeTransformable

public protocol EncodeTransformable {
    associatedtype EncodeSourceType

    associatedtype EncodeTargetType: Encodable

    func transformToEncodable(value: EncodeSourceType) throws -> EncodeTargetType
}

public protocol DecodeTransformable {
    associatedtype DecodeSourceType: Decodable

    associatedtype DecodeTargetType

    func transformFromDecodable(value: DecodeSourceType) throws -> DecodeTargetType
}

The DateFormatter has already been adopted to the Transformable protocol which allows to use the encode and decode API when passing an DateFormatter as there was no change.

extension DateFormatter: Transformable {
    public func transformToEncodable(value: Date) throws -> String {
        return self.string(from: value)
    }
    
    public func transformFromDecodable(value: String) throws -> Date? {
        return self.date(from: value)
    }   
}

Even nicer developers can now pass any kind of EncodeTransformable or DecodeTransformable to the encode and decode API. For example a simple IntToStringTransformable.

struct Article: Codable {
    var id: String
    var body: String
    var date: Date?

    init(from decoder: Decoder) throws {
        id = try container.decode("id", using: IntToStringTransformable())
        body = try container.decode("body")
        date = try container.decode("date", using: DateFormatter())
    }
}

struct IntToStringTransformable: Transformable {
    func transformFromDecodable(value: Int) throws -> String {
        return .init(value)
    }
    
    func transformToEncodable(value: String) throws -> Int? {
        return Int(value)
    }
}

Additional thoughts: The current Transformable implementation for the DateFormatter will return an optional Date, based on the date(from:) API of the DateFormatter itself, when invoking the transformFromDecodable API.

Before a DecodingError has been thrown when the Date is nil. I was not a 100% sure if throwing an Error or returning an optional Date is better.

So I chose the second option so that the developer can decide if either to provide a default value or manually thrown an DecodingError.

I'm excited about your feedback ✌️

Hi John! I really enjoyed the philosophy of this library and I'm happy to have these improvements to Codable in the open.

One of the frustrations that i always have to workaround in Codable is having a way to safely decode an array of objects safely ignoring the ones that fail to decode, instead of blowing up the entire array as the default system does.

So trying to decode { "numbers": [ 1, 2, "3", 4 ] } to let numbers: [Int] won't fail, instead you will receive an array of [1, 2, 4].

I thought that this may be a common enough use case to include it in the library so I spend some time porting it and trying to match the style of this code. I also wrote test to make sure the normal case (all elements are correct) works and that the case of elements failing also works. (There are 2 assertions in the same test, if you prefer to split them feel free to tell me).

Suffices to say that if you don't consider this to be inline with the library's intend feel free to close it 😉

Why

Publish supports the use of a custom DateFormatter for decoding dates. It would be nice to allow users to also use ISO8601DateFormatter as the custom date formatter.

See previous discussion on the issue here: Publish PR #77.

Problem

AnyDateFormatter does not provide all the properties that Publish needs in order to use it as a replacement for DateFormatter.

Solution

Add two properties to the AnyDateFormatter protocol to allow us to replace DateFormatter in Publish.

• timeZone: TimeZone!
• dateFormat: String!

dateFormat is readonly as Publish only needs to read this value for debugging purposes. DateFormatter already implements this requirement, so we only needed to provide a value for ISO8601DateFormatter that will be useful during debugging.

You can see how these changes would be integrated into Publish by looking at this draft PR. https://github.com/JohnSundell/Publish/pull/109

Hi John,

The key motivation for this addition was to enable propagation of errors, primarily DecodingError.typeMismatch, when attempting to decode values into optional properties. While the existing functionality for optionals, supported by the try? notation, is valid for many use cases, it does not allow for proper alerting when the key is present, but of an incorrect type.

I am certainly open to any feedback and very much appreciate your consideration.

code comes directly from https://github.com/evermeer/Stuff#codable Feel free to use any of it in Codextended. it's not formatted conform your coding style and not tested for incompatibilities with your code.

Here is a short list of what you could do with this.

let json = yourEncodableObjectInstance.toJsonString() let data = yourEncodableObjectInstance.toJsonData() let newObject = try? YourCodableObject(json: json) let newObject2 = try? YourCodableObject(data: data) let objectArray = try? [YourCodableObject](json: json) let objectArray2 = try? [YourCodableObject](data: data) let newJson = objectArray.toJsonString() let innerObject = try? TestCodable(json: "{"user":{"id":1,"naam":"Edwin"}}", keyPath: "user") try initialObject.saveToDocuments("myFile.dat") let readObject = try? TestCodable(fileNameInDocuments: "myFile.dat") try objectArray.saveToDocuments("myFile2.dat") let objectArray3 = try? TestCodable

This change adds support for the common ISO-8601 date format, by making it possible to pass a ISO8601DateFormatter when encoding or decoding a date (on supported platforms).

Hi!

This allows decoding values from nested containers like this:

{
    "a": {
        "b": {
            "c": "hello world"
        }
    }
}

with:

decoder.decode(["a","b","c"])

I thought of adding a dot syntax (eg: decoder.decodeNested("a.b.c"), but found it unnecessary.

I'm not sure if CodextendedDecodingError works with Codextended's philosophy...

It also may be good to add encoding and update readme.