Currently, the components responsible for rendering itineraries (e.g. ItineraryLegs, WalkLeg, WaitLeg) contain complex logic that transforms each itinerary. For example, they
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:
Currently, the components responsible for rendering itineraries (e.g.
ItineraryLegs,WalkLeg,WaitLeg) contain complex logic that transforms each itinerary. For example, theyIMO a good example of how to move out such complex logic is the
compressLegs(), which is being used byItineraryLegs. 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: