Improve route response decoding. #446
Conversation
| } | ||
|
|
||
| return "" | ||
| }).joined(separator: "\n") |
There was a problem hiding this comment.
Not bad. What do you think about further customizing the Quick Look implementation of this type to show the target coordinate when present instead of the main coordinate?
There was a problem hiding this comment.
Interestingly debugQuickLookObject doesn't work for me in Swift, when using Objective-C it works as expected. Will add targetCoordinate ?? coordinate though.
| waypoint.separatesLegs = waypointInOptions.separatesLegs | ||
| waypoint.allowsArrivingOnOppositeSide = waypointInOptions.allowsArrivingOnOppositeSide |
There was a problem hiding this comment.
Aside from the tests below, what would be a good way to prevent a future option from getting overlooked this way? How about copying the waypointInOptions and overwriting the fewer properties that are available in the decodedWaypoint. This could be good fodder for tail work; not essential for this PR.
There was a problem hiding this comment.
Then again, #388 would make a finer distinction between a requested waypoint and a received waypoint, such that the developer would be responsible for keeping track of the requested waypoints’ details separately, mirroring the API response format. But until that change lands someday, this is a good change to have for consistency.
There was a problem hiding this comment.
I was thinking about using a copy of waypointInOptions and assigning only minimum number of essential properties, but public let coordinate: CLLocationCoordinate2D prevents me from assigning it from decodedWaypoint. I'm not sure why coordinate is declared as let whereas others use var, but if that's okay to make coordinate var as well it'd make it possible.
Closing #445.