Fix stop viewer next days departures #1005
Conversation
…s exist for a pattern.
binh-dam-ibigroup
requested review from
daniel-heppner-ibigroup
and removed request for
AdrianaCeric
| ): V { | ||
| let entry = entries[key] | ||
| if (!entry) { | ||
| entries[key] = entry = newValue(key) |
There was a problem hiding this comment.
I can't say I've seen this done before in Javascript. Had to look run an experiment to see what happens here. I wonder if it would be more clear if it were on two lines?
| @@ -66,6 +65,17 @@ export interface Time { | |||
| tripId: string | |||
| } | |||
|
|
|||
| export interface PatternStopTimes { | |||
There was a problem hiding this comment.
This type is different from the one returned in the GraphQL API, which is an issue for the Nearby View. Let's get this merged in and then we can figure out what to do in the Nearby View branch before merging it.
| } | ||
|
|
||
| /** Helper to sort and group stop times by pattern by service day */ | ||
| export function groupAndSortStopTimesByPatternByDay( |
There was a problem hiding this comment.
This logic is super clean, but since the shape of the graphql stoptimes response is different it might have to be adapted in the future. I wonder if we shouldn't build it for the new API and then transform the old API into the new shape for now?
There was a problem hiding this comment.
This can come later
daniel-heppner-ibigroup
assigned binh-dam-ibigroup and unassigned daniel-heppner-ibigroup
Description
This PR fixes the departure days in the Stop Viewer for trips that only have departures in the next days and not the current day. Specifically, trip departures are grouped by departure day (or service day) based on the data returned by OTP instead of an arbitrary rule.
PR Checklist