feat: departures multi-section auto-sizing

[digitalcora]

Best reviewed per-commit, there are a couple independent refactors.

• Update departures widget generation to pass layout parameters from configuration to the frontend.

• Replace existing auto-sizing implementation, which only worked for a single section, with a version that handles multiple sections using the layout parameters.

• The auto-sizing itself (independent of the React component) is unit-tested. These are the first real frontend tests in Screens, so we take the opportunity to:

  • Update Jest to its latest version.

  • Replace the third-party @types/jest package with a direct dependency on @jest/globals, which is already part of Jest. The only advantage of the former is that it allows using describe, test, etc. without importing them.

  • Add eslint-plugin-jest to our ESLint setup.

  • Add fishery for defining factories to build test data.

---

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

[sloanelybutsurely]

quibble (non-blocking): i'm hesitant to rely on typescript's separate namespaces for types and values in this way. could we call one of these DepartureTime things something else?

update: i see this is pattern is used a lot throughout this commit. if this is already an established pattern elsewhere please feel free to disregard.

[digitalcora]

I used this pattern in places where a distinct "object" returned by the server corresponds exactly to the props of the component which renders an instance of that object. A DepartureTime (value) is a component which renders a DepartureTime (type). Within their namespaces, I think it makes sense to call each one of these by that name. But things don't always line up this way, as with e.g. the component one level above this, DepartureTimes: in this case the "props type" has a distinct name and is not exported.

export type TimeWithCrowding = { /* ... */ };

type Props = { timesWithCrowding: TimeWithCrowding[] };

const DepartureTimes: ComponentType<Props> = ({ timesWithCrowding }) => { /* ... */ };

I'd hesitate to say there's an "established pattern", since unfortunately a lot of the existing codebase just doesn't have explicit types at all (which is why we currently allow implicit-any). If anything it currently leans towards using separately-named "props types" in all cases. So I guess I'm proposing that we establish this as a pattern 🙂 What do you think?

In any case, thanks for calling this out, since I realized we should be using import type in places where we only use the type. It looks like the linter has a rule to enforce this but it's off by default. I'll see what happens when we turn it on.

[digitalcora]

Okay, the lint rule gives 162 errors on the current codebase... it looks like it's less sophisticated than I thought, and just errors whenever you import a type without using type, even if the name has no overlap with a value. (Though it seems like this could have advantages for bundle size anyway, so maybe we should think about turning it on, separately?)

I looked at all the imports across changed files in this PR, but as far as I can see, there actually isn't any place where I imported a value+type name and only used the type, so I haven't added any type keywords here.

[sloanelybutsurely]

If anything it currently leans towards using separately-named "props types" in all cases. So I guess I'm proposing that we establish this as a pattern 🙂 What do you think?

This is my personal preference so I'm on-board!

As an aside, I also prefer to use something like zod to parse external data to ensure that types for it are accurate and not just wishful thinking. 📌 We can put a pin in that for now though.

[sloanelybutsurely]

LGTM (as far as I can tell that is...). It might still be a good idea to have someone else take a look because I'm really just looking at code with little context. I've made very little judgement based on behavior here.

We can type names as-is and have that discussion more broadly whenever we feel like it ("never" also an option for when to chat about it)

[cmaddox5]

Really digging the approach here. And the code is organized in a way that makes this complicated operation very approachable.

[github-actions]

Coverage of commit 683ddd1

Summary coverage rate:
  lines......: 44.5% (2845 of 6394 lines)
  functions..: 42.0% (1019 of 2428 functions)
  branches...: no data found

Files changed coverage rate:
                                                                          |Lines       |Functions  |Branches    
  Filename                                                                |Rate     Num|Rate    Num|Rate     Num
  ==============================================================================================================
  lib/screens/v2/candidate_generator/dup/departures.ex                    |88.2%    136|77.3%    22|    -      0
  lib/screens/v2/candidate_generator/gl_eink.ex                           |17.4%     46|16.7%    18|    -      0
  lib/screens/v2/candidate_generator/widgets/departures.ex                |90.2%     41|84.6%    13|    -      0
  lib/screens/v2/widget_instance/departures.ex                            |81.0%    142|81.8%    33|    -      0

Download coverage report