Serialization in Swift

Evolution Discussion
2

One issue I would like the new API to address is to allow more customization points around single properties. I can provide the following cases:

  1. When I want to specify date formatting, the existing Codable API only allows me to set dateEncodingStrategy on the JSONEncoder object. In most scenarios which I have encountered the date formatting logic should only be written once (in the data type definition I suppose), but the current Codable API requires every use site of the data type specify the rule (which could easily be got wrong or just forgotten in the copy&paste process). Much worse is that we can't specify two different dateEncodingStrategy on two different properties in a single data type (the data field may come from sub systems, and it should be easier to write this behavior on the client than to persuade server guys to change their logic).

  2. Sometimes a json field may not exist or just be null, or it may have a json object type that is different from the client's expectation. In some cases I'd rather have a single optional type to handle all the cases (like Optional<String>), instead of the whole decoding process fails. In the object type mismatching subcase, I prefer there is some mechanism which could allow this information sent back to the caller of decoder while the other fields could be decoded normally. When the server API got one minor field wrong in the production environment, an iOS engineer just doesn't want there is no ANY data in tableView/collectionView ;-)

  3. A way to specify nested fields more easily. Currently in the Codable API, we have to define separate data types to handle the nesting structure in a JSON object. Sometimes I want to flatten the structure on the client side (e.g. for better uniform representation, easier to do some abstraction), but it may be difficult (or impossible) to let server guys do the flattening logic for me. So I'd prefer that there will be rather easy way to specify a nested field (like @field("outerObj.innerObj.modifiedDate") var modifiedDate: Date?). This could save me a lot of time.

  4. Currently in the Codable API, when I want to have some customization around a single property, I have to rewrite ALL the auto-generated code in the encode/decode methods. This is rather cumbersome in cases that a data type may contain dozens of properties. My point is that customization around one property should not affect the existing logic for the other properties in the same data type.

The cases I mentioned above are ALL from the business code I encountered/wrote in the past several years, so I really hope the new API could address these issues.

26 Likes