tristanhimmelman / ObjectMapper

Simple JSON Object mapping written in Swift
MIT License
9.14k stars 1.03k forks source link

What do you think about Codable of Swift 4? #823

Closed lexrus closed 4 years ago

jassadakorn commented 7 years ago

We don't need to use objectMapper anymore

dcortes22 commented 7 years ago

@jassadakorn why not?

jassadakorn commented 7 years ago

@dcortes22 Because objectMapper have to check Json key for each property in mapping function but Codable don't have to check ( See also ) . It's mean the key can be invalid by human error if we use objectMapper

dcortes22 commented 7 years ago

Very interesting thanks for the clarification!

shiyizju commented 7 years ago

With Codable, I guess the variable's name must be same as json key, and every variable will be coded into json?

devxoul commented 7 years ago

ObjectMapper still provides more detailed functionality.

skydivedan commented 7 years ago

With Codable, the property name does not need to be the same as the JSON key, you can easily map to a different name.


This does change things for me, though. I pour JSON into Realm objects. The main reason I use ObjectMapper is for mapping ISO8601 Strings into Date objects, since Realm has no mechanism to do this. I don't know what the folks at Realm think about Codable, (and I haven't thought this through yet myself!), but if Codable could be adopted in Realm, then all those DateTransforms could drop away... which might mean that I could drop ObjectMapper.

I don't know if this is truly feasible, but something to think about.

yariksmirnov commented 7 years ago

I use ObjectMapper in cause of really useful support of custom transformations. In case of Realm I created my custom transformers to create-or-update objects which are referenced by ids in REST APIs.

loudmouth commented 7 years ago

I think the nested keypath options of ObjectMapper provide functionality that make it more adaptable to a wide variety of JSON API's. Being able to do things things like:

contentTypeId   <- map["contentType.sys.id"]

Rather than having additional nested structs is a big advantage of ObjectMapper for interfacing with certain APIs.

aksswami commented 7 years ago

But the same can be achieved via Codable and as this is the language feature, so it will be more widely used and also we will have consistent parsing across most of the projects.

pmusolino commented 7 years ago

Codable has the .toJSON() feature?

aksswami commented 7 years ago

Yes, Codable have Encoder and Decoder which we can use for toJSON and fromJSON.

pmusolino commented 7 years ago

OK, but the encoder is automatic like ObjectMapper, or you have to explicit how to encode the variables?

loudmouth commented 7 years ago

@Codeido here is the WWDC video describing "What's New in Swift"

jonasman commented 7 years ago

Im also planning to replace ObjectMapper in all my projects (even professional ones) with Swift4's Codable.

emoryalimam commented 7 years ago

here’s a great guide on using Codable in Swift 4: http://swiftjson.guide

aksswami commented 7 years ago

The best guide for Codable I came across:- http://benscheirman.com/2017/06/ultimate-guide-to-json-parsing-with-swift-4/

jonasman commented 6 years ago

I tried to convert from ObjectMapper to Codable and i must it is such a pain... OM is superior.

guitcastro commented 6 years ago

@jonasman Can you please elaborate why?

tomaskraina commented 6 years ago

For anyone still interested in the pros and cons between decodable vs ObjectMapper, I've found a nice writeup: https://medium.com/bbc-design-engineering/codable-vs-objectmapper-af5fe8e8efd5