Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: feat(TripPlanner): transit leg and itinerary locations #2251

Merged
merged 14 commits into from
Dec 10, 2024

Conversation

thecristen
Copy link
Collaborator

@thecristen thecristen commented Dec 6, 2024

Summary of changes

Asana Ticket: Trip Planner Preview | Details: Transit segment and Trip Planner Preview | Details: Location Item

Somewhat rough around the edges and still missing some acceptance criteria, but wanted to get a chance for review before leaving for a couple days. Notable items remaining:

  • Missing the trip headsign - we can add this to the query in OpenTripPlannerClient
  • It should only show one location in between two legs, not both the end of one leg + beginning of next leg. I tried to write some logic to look at those two legs and consolidate them while preferring to display the transit icon over the generic location pin... but it was terrible and didn't quite work. I'm thinking it might be better just to adjust OpenTripPlannerClient to give us the stop's locationType .. then we could read that value to decide which icon to render.
  • The text needs some improvement for commuter rail train rides - in the AC it's technically "TBD" but IMO it should at least show the train number.
  • The MBTA stop names are supposed to be clickable links to their respective stop pages
  • I haven't yet tested this against really long location names (it should wrap a certain way)
image

@thecristen thecristen requested a review from a team as a code owner December 6, 2024 22:40
@thecristen
Copy link
Collaborator Author

image okay, not quite there yet heh

@joshlarson
Copy link
Contributor

I'm thinking it might be better just to adjust OpenTripPlannerClient to give us the stop's locationType .. then we could read that value to decide which icon to render.

Could we do something even dumber than that, and just have some logic at time-of-rendering that tells a walking segment not to render the locations at either end unless it's the beginning or end of an itinerary?

Copy link
Contributor

@joshlarson joshlarson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks so great right now!

I have a thought about <.place />. What if, instead of wrapping each <.leg /> in two places (which guarantees that all places will get doubled up, as it currently is), we wrapped only transit legs with <.place />'s and left walking legs place-less. We would then need to add a location-dot-icon place at the beginning and the end of the whole itinerary.

(If we do ☝️then it probably makes sense to have a <.transit_leg /> include its places and leave them out of the main itinerary_detail function, but that's kind of a minor thing.)

In order to get that fully 100% correct, I think we'd need to add a data transformation layer to solve (at least) two corner-cases:

  • Transferring without walking, which can happen if you need to transfer at a bus stop that serves multiple routes, or if you need to switch green line trains in the Central Subway. (This would involve having a "waiting leg", which hasn't been fully designed yet)
  • If the itinerary starts or ends exactly at a station or stop, then we don't want to double up the locations (like in the screenshot below)
    Screenshot 2024-12-09 at 5 02 48 PM

IMO ☝️ these corner cases and the data transformation layer can happen as fast-follow-up PR's, rather than getting lumped into this one. If we get rid of the guaranteed duplication of <.place />'s, then I'm good to merge this.


TL;DR - there are a bunch of corner cases that we need to address before releasing, but can happen as follow-up PR's. For this PR, I'm good to merge once we get rid of the duplicated <.place />'s?

@joshlarson joshlarson self-assigned this Dec 10, 2024
Comment on lines +68 to +71
|> assign(:start_place, List.first(assigns.itinerary.legs).from)
|> assign(:start_time, List.first(assigns.itinerary.legs).start)
|> assign(:end_place, List.last(assigns.itinerary.legs).to)
|> assign(:end_time, List.last(assigns.itinerary.legs).stop)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole blob is kind of gross, but @thecristen and I talked offline, and we're going to remove it in a fast-follow PR, so that this one doesn't get bloated.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Side note, at least the variable name lengths decrement by one letter per line, so they form a nice shape.

@thecristen thecristen merged commit 92cc1b3 into main Dec 10, 2024
16 of 17 checks passed
@thecristen thecristen deleted the cbj/transit-leg-component branch December 10, 2024 22:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants