Open edgarss opened 4 years ago
I started using ObjectMapper after using Decodable/Codable because most of the time, API at our place changes consistently during mobile development phase. I found ObjectMapper easier to adapt to unknown changes. After a while, the pattern lives in many projects while API patterns changes from project to another. I feel more comfortable to use ObjectMapper to adapt to changing API, knowing the pattern will change all the time. In an ideal scenario, I think the pro/con of native Codable over ObjectMapper is worth discussing.
Can you give an example where ObjectMapper is more adaptable? because if its the json keys changing you can easily update that using CodingKeys.
struct AuthToken: Codable {
enum CodingKeys: String, CodingKey {
case token = "preauth_token"
case status
}
let token: String
let status: String
}
This is all the code you need with Codable and you won't need required init?(map: Map) or func mapping(map: Map) any more.
One problem I had was API changing the key and also value types. I like having the flexibility of having an object with optional values, it makes sense to do it in Codable but ObjectMapper helps mitigate the risk of having to maintain example codes
name = (try? values.decode(String.self, forKey: AuthToken.CodingKeys.name )) ?? ""
In my understanding, having required init(from decoder: Decoder) {
in Decodable means having to write custom mapper to every keys.
In project with multiples objects having >10 keys each, code can get really messy.
I think transform line of ObjectMapper is more readable than Codable, although not use often in our project (two endpoints return date in different format).
I think mapping to AF or Realm is also a nice little bonus, without having to add more code.
Code is much cleaner and its one less 3rd party library to depend on with Decodable/Codable. also allows you to use responseDecodable in alamofire instead of responseJson like currently, making everything much simpler and cleaner