-
Notifications
You must be signed in to change notification settings - Fork 138
Description
Currently, the components responsible for rendering itineraries (e.g. ItineraryLegs
, WalkLeg
, WaitLeg
) contain complex logic that transforms each itinerary. For example, they
- insert waiting legs between other legs in some cases
- when to show bicycle and/or walking legs before/after some transit
- interlines legs only in some very specific cases
- calculate transfer/"gap" times between legs
- etc.
IMO a good example of how to move out such complex logic is the compressLegs()
, which is being used by ItineraryLegs
. There are probably other good examples!
This is a broader topic to discuss, but it seems like digitransit-ui de-facto has a slightly different semantic model of an itinerary than OTP. It might be worth it making this semantic model more explicit, e.g. by documenting it, adding mapping functions like digitransitItineraryFromOtpItinerary()
; This potentially reduces the legibility of the code, though.
The following resources explain the problem and possible solutions in a general manner: