Decodable
Simple and strict, yet powerful object mapping made possible by Swift 2's error handling. Greatly inspired by Argo, but without a bizillion functional operators.
struct Repository {
let name: String
let description: String
let stargazersCount: Int
let language: String?
let sometimesMissingKey: String?
let owner: User // Struct conforming to Decodable
let defaultBranch: Branch // Struct NOT conforming to Decodable
var fullName: String { return "\(owner.login)/\(name)" }
}
extension Repository: Decodable {
static func decode(j: Any) throws -> Repository {
return try Repository(
name: j => "nested" => "name",
description: j => "description",
stargazersCount: j => "stargazers_count",
language: j => "language",
sometimesMissingKey: j =>? "sometimesMissingKey",
owner: j => "owner",
defaultBranch: Branch(name: j => "default_branch")
)
}
}
do {
let json = try NSJSONSerialization.JSONObjectWithData(data, options: [])
let repo = try [Repository].decode(json)
} catch {
print(error)
}
How does it work?
A protocol
public protocol Decodable {
static func decode(json: Any) throws -> Self
}
A parse-function
public func parse<T>(json: Any, path: [String], decode: (Any throws -> T)) throws -> T
And shameless operator-overloading
The too-many generated overloads, all calling the parse-function, can be found in Overloads.swift. Return types include T?, [T?], [T?]?, Any and [String: T]?. When conditional protocol conformance is supported in Swift this won't be necessary, and automagic decoding of infinitly nested generic types (like [[[[[[[[[A???]]: B]]]?]]?]]) would work.
An overload may look like this:
public func => <T: Decodable>(json: Any, keyPath: KeyPath) throws -> T
KeyPaths
Keypaths can be created from string and array literals as well as with explicit initializers. They can also be joined using the operators => and =>?. =>? is another operator that indicates that nil should be returned if the key to the right is missing.
- When composing
=>and=>?operators in the same keypath, the strictness of=>is still honoured. - Optional key paths (
=>?) require an optional return type
let a: KeyPath = "a"
let b: KeyPath = ["a", "b"]
let c: KeyPath = "a" => "b" => "c"
let string: String? = json =>? "key1" => "key2" => "key3"`
^^^^ allowed to be missing
Errors
Errors will be caught and rethrown in the decoding process to backpropagate metadata, like the JSON object that failed decoding, the key path to it, and the root JSON object.
From DecodingError.swift:
public enum DecodingError: ErrorProtocol, Equatable {
/// Thrown when optional casting from `Any` fails.
///
/// This can happen both when trying to access a key on a object
/// that isn't a `NSDictionary`, and failing to cast a `Castable`
/// primitive.
case typeMismatch(expected: Any.Type, actual: Any.Type, Metadata)
/// Thrown when a given, required, key was not found in a dictionary.
case missingKey(String, Metadata)
/// Thrown from the `RawRepresentable` extension when
/// `init(rawValue:)` returned `nil`.
case rawRepresentableInitializationError(rawValue: Any, Metadata)
/// When an error is thrown that isn't `DecodingError`, it
/// will be wrapped in `DecodingError.other` in order to also provide
/// metadata about where the error was thrown.
case other(ErrorProtocol, Metadata)
}
let dict: NSDictionary = ["object": ["repo": ["owner": ["id" : 1, "login": "anviking"]]]]
do {
let username: String = try dict => "object" => "repo" => "owner" => "name"
} catch let error {
print(error)
}
//
// MissingKeyError at object.repo.owner: name in {
// id = 1;
// login = anviking;
// }
Handling Errors
Expressions like j => "key" will throw directly, and catch-statements can be used to create the most complex error handling behaviours. This also means that try? can be used to return nil if anything goes wrong instead of throwing.
For convenience there is an operator, =>?, that only returns nil on missing keys, for APIs that indicate null in that manner, and to aid working with different response formats.
| Overload | Null Behaviour | Missing Key Behavior | Type Mismatch Behaviour | Errors in subobjects |
|---|---|---|---|---|
=> -> T |
throws | throws | throws | uncaught (throws) |
=> -> T? |
nil | throws | throws | uncaught (throws) |
=>? -> T? |
nil | nil | throws | uncaught (throws) |
try? => -> T |
nil | nil | nil | caught (nil) |
Customization
Int, Double,String, Bool, Date (ISO8601), NSArray, and NSDictionary types that conform to DynamicDecodable with the following declaration:
public protocol DynamicDecodable {
associatedtype DecodedType
static var decoder: (Any) throws -> DecodedType {get set}
}
This allows Decodable to implement default decoding closures while allowing you to override them as needed.
// Lets extend Bool.decoder so that it accepts certain strings:
Bool.decoder = { json in
switch json {
case let str as String where str == "true":
return true
case let str as String where str == "false":
return false
default:
return try cast(json)
}
}
Note that when extending new types to conform to Decodable there is really no point in conforming to DynamicDecodable since you already control the implementation. Also note that the decoder properties are intended as "set once". If you need different behaviour on different occations, please create custom decode functions.
The default Date.decoder uses a ISO8601 date formatter. If you don't want to create your own decode closure there's a helper:
Date.decoder = Date.decoder(using: formatter)
When Decodable isn't enough
Don't be afraid of not conforming to Decodable.
let array = try NSArray.decode(json => "list").map {
try Contribution(json: $0, repository: repo)
}
Tips
- You can use
Decodablewith classes. Just make sure to either call arequiredinitializer on self (e.gself.init) and returnSelf, or make your classfinal. ( This might be a problem though) - The
Decodable-protocol and the=>-operator should in no way make you committed to use them everywhere.
Compatibility
| Swift version | Compatible tag or branch |
|---|---|
| Swift 4.0 | 0.6.0 |
| Swift 3.0 | v0.5 |
| Swift 2.3 | v0.4.4 |
| Swift 2.2 | v0.4.3 |
Note on Swift 4.0 usage
Due to collisions with the standard library you will have to import ambiguous symbols specifically, in addition to Decodable as a whole.
This means you likely want the following
import Decodable
import protocol Decodable.Decodable
and you can import other symbols, e.g KeyPath, DecodingError, in a simlilar fashion (using import struct and import enum)
964 Dec 14, 2022
3.8k Jan 5, 2023
749 Dec 5, 2022
3 Feb 13, 2022
1.1k Sep 8, 2022
249 Jun 29, 2022
8 Nov 20, 2022
0 Dec 17, 2021
21 Aug 1, 2022
611 Oct 23, 2022
10 Sep 29, 2021
36 Sep 15, 2022
3 Feb 14, 2022
0 Nov 30, 2021
7 May 13, 2022
0 Oct 20, 2022
0 Dec 9, 2021
287 Nov 11, 2022
8.5k Jan 3, 2023