Alex Simpson
Jordan MorganThe absolute saddest sight imaginable when you are working with codable models
Maximilian@jordanmorgan 😂 It's true. I wish Apple added support for using another coding key(s) to specify a path to the object to parse.
@JediMax That would be golden. Right now there are really only one of two ways to solve it. Custom encoding/decoding/inits or just a ModelContainer type of struct. I do the later and just live with it.
Ryan Ashcraft@jordanmorgan excuse my ignorance, what’s the challenge with this?
@ryanashcraft The model data is really what's under "data" - but with codable I can't key it down that way without writing boilerplate encode/decode/inits. So I need something like modelContainer.data when really all I want is simply data.
More details here: https://www.donnywals.com/flattening-a-nested-json-response-into-a-single-struct-with-codable/
@jordanmorgan ah gotcha. I prefer to make a struct representing the API response and offer a way to convert to the canonical app model. Some boilerplate alas but not the worst thing.
Michał Kasprzyk@ryanashcraft @jordanmorgan I also have similar approach. Might feel as a lot of boilerplate at first, but when you want to change something only for the API it’s much easier. There is no coupling between API models and domain logic/models
Pedro Vereza@ryanashcraft @jordanmorgan I think it's the "success" : true part.
Mostly annoying when you get a response code 200 (which means the same thing) and now you need an extra Struct with CodingKeys just to read `data`
Andy Ibanez@jordanmorgan This awakened some memories I wanted to suppress.
@andy I am sorry to take you back to that dark place 🙈🙈🙈🙈