refactor: Extract timetable template to its own component

[joshlarson]

Scope

The end goal of this work is to have a timetable component whose invocation will be (almost) as simple as <.timetable timetable={@timetable} />. That will make it easier to render the Harbor Loop Ferry with two timetables on the same page, and give us more flexibility in how we render different types of timetable pages in the future.

This PR goes about halfway - it splits out a separate component for the timetable (actually two... more on that in a moment), and adds more structure to the %Timetable{} struct, introduced in #3206. The remaining refactor work is to pull the last bits of non-user-interaction data (i.e. alerts) into the Timetables module. Once we do that, rendering a different layout for the Harbor Loop Ferry should be almost trivial.

Two timetables?

We already have two different timetable implementations, although they're currently kind of muddled together, using the somewhat opaquely-named use_pdf_schedules? flag.

• When use_pdf_schedules? is true, then the timetable template expects @timetable_schedules, @header_stops, and @header_schedules to be set.
• When use_pdf_schedules? is false, then the timetable still expects @header_stops and @header_schedules to be set, but it gets its cell data from @trip_schedules and @trip_messages instead (along with data from a few other fields, like @track_changes.

A core part of this PR makes is to explicitly separate those two implementations into <.linear_timetable /> (so named because it can't support loops or trips that visit the same stops in different orders, and <.timetable />, which has no such constraint, but has fewer features (e.g. it doesn't support track changes... for now!). Most of the rest of this PR is cleanup around the edges of the contract between <.timetable /> and the template that calls it, as well as the %Timetable{} struct that gets passed in.

Asana Ticket: ⛴️ Make timetable its own component(s)

Implementation

Warning

This PR is quite large, so I'll walk through it commit-by-commit.

Groundwork

Tip

These commits lay the groundwork for all of the upcoming work - converting a bunch of HEEx code into components and updating some out-dated variable names

• refactor: Extract timetable rendering to a component
• refactor: Convert _timetable_schedule template into <.timetable_cell /> component
• refactor: Change use_pdf_timetable? to linear_timetable? and swap the sense

Cleanup

Tip

A lot of the commits in this PR are relatively minor cleanup's around the edges. This is the first instance of those.

• refactor: Replace content_tag invocations with regular HEEx code
• refactor: Extract <.timetable_cell_wrapper /> and remove unnecessary variables
• refactor: Use @value syntax instead of assigns[:value]
  • The assigns[:value] invocations were necessary when this code was in the template, but the way I pulled them into the component meant they were guaranteed to always be assigned (even if they were assigned as nil), meaning that @value should work just fine now.
• fix: Map lookup syntax error
  • Well, not exactly a syntax error, but the || %{} was inside of the lookup [brackets] - i.e. map[key || %{}]. I'm guessing it was originally intended to be map[key] || %{}, but the fact that everything already worked (and that key in this context was guaranteed never to be falsey), means that it was easier to just get rid of the || %{} entirely.

Two timetables!

Tip

See discussion above. This is where I split the timetable glob into two fully different components and trimmed down the attributes passed into each.

• refactor: Split <.timetable /> and <.linear_timetable /> into separate components
• refactor: Remove portions of timetable components that aren't needed
• refactor: Compute cell_background in a function and remove a for loop
• refactor: Extract <.stop_header_cell />
• refactor: Iterate over @timetable_schedules instead of @header_stops

%Timetable{} struct

Tip

This section is where I started adding more structure to the %Timetable{} struct and integrating it more tightly with the timetable component.

• refactor: Assign timetable directly to the conn instead of timetable_schedules
• cleanup: Remove non-ferry section, and add a warning comment
  • We will eventually want to add this (or something like it) back, but I didn't want to deal with speculative code right now.
• refactor: Use header_trips instead of header_schedules in the timetable
• refactor: Make timetable rows their own struct
• refactor: Move stop header calculation to timetable backend
• refactor: Make @header_schedules not required in timetable template
• cleanup: Remove stop_id field from %Timetable.Cell{}
• refactor: Move trip header calculation to timetable backend
• refactor: Rename variables to avoid calling everything trips
  • Purely a code-cosmetic change, but when the Timetables module was first introduced, it didn't deal with %Schedules.Trip{} structs at all, so trips was a relatively non-confusing name for a list of %Schedule{}-lists (the schedules for a trip). This PR added handling for actual trip structs, so finding a new name for the variable formerly known as trips became much more virtuous.

Screenshots

No visual changes.

How to test

This should have no actual changes, so take a look at some timetables for commuter rail and timetables for ferry (don't forget the loop ferry routes) and compare them to their prod equivalents.

Note

The Harbor Loop Ferry doesn't start until June 29, and doesn't run on weekends, so the fact that it doesn't a show a timetable for today is a feature, not a bug.

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1215424202403217

[thecristen]

There are three broken tests from the old timetable view test file, please fix!
I think the rest looks and works great. 🚀

[thecristen]

✨