Obvious date adding, deadlines inside modules, region filtering - #50
Merged
Merged
Conversation
Two things a student could not find. An undated task showed a 34px dashed box with transparent text — a blank square that says nothing about what it is for, so nobody clicked it. Until there is a date, the control is now a labelled "+ Add date" button that swaps to a focused date input; once set, the input shows the date as before. The checklist stays a checklist rather than a wall of pickers, which is why the box was small to begin with, but it no longer hides the feature. The button carries its own accessible name, so the task it belongs to is announced. The deadline panel now also sits beside every module's Overview, so "what is actually due" no longer requires leaving the module. That was not possible before. The college list persists as one whole array and had two owners — Application Tracking and the dashboard's deadline hook — so whichever saved last replaced what the other had just written. The dashboard dodged it by pausing its hook whilst a module was open, which is exactly what ruled out showing the panel inside one. So the list has a single owner now: ApplicationsContext, wrapped around everything that reads or writes it. Both callers share that one array, a change made in either place is visible in the other with no refetch, and the pause becomes a refresh key — entering or leaving a module refetches the sources this hook still owns, without the panel ever going dark. A new test covers the case the pause existed for: a college added while the panel is live survives a tick. Scholarship tracker items look like the same problem and are not — they are rows in their own table written one at a time, so concurrent writers cannot overwrite each other. Left alone. The rail is built once on the dashboard and passed down, rather than each module calling the hook: a second instance would give the student's ticked-off list two owners and reintroduce the bug one layer down.
"Nearest" only reorders the list — a student set on the Northeast still had Boston first and Arizona fifth. Region is a filter, which is the thing they actually wanted. The colleges table already carries a region, but it is the four census ones, and they are far too coarse to browse by: "West" is Seattle, Phoenix and Honolulu together, "Northeast" runs Maine to Pennsylvania. So this adds a finer set — New England, Mid-Atlantic, Southeast, Midwest, South Central, Mountain West, Pacific — derived from the state, narrow enough that picking one meaningfully shortens the list. The census map stays exactly as it is. It is stored on every college row and feeds the distance dimension of the match score; re-cutting it would silently restate every student's results for a UI change. The student's own region is labelled "(yours)" rather than preselected — someone browsing Discover is often looking for somewhere they are not. The filter also applies to hidden gems, which already take care not to leak a pathway the student opted out of; an out-of-region gem is the same kind of leak once they have said where they are looking. Territories have no search region, so an explicit pick is the only thing that ever hides them. Tests cover that all 50 states and DC land in exactly one region — a missing state would silently vanish from the list the moment anyone filtered.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Deploying timeline-prototype with
|
| Latest commit: |
2888913
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://504c184a.timeline-prototype.pages.dev |
| Branch Preview URL: | https://ui-dates-rail-and-regions.timeline-prototype.pages.dev |
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three things, from the screenshot and the follow-ups.
1. It was not obvious a date could go there
An undated task rendered a 34px dashed box with transparent text — a blank square that says nothing about what it is for, so nobody clicked it.
Until there is a date, the control is now a labelled "+ Add date" button that swaps to a focused date input; once set, the input shows the date as before. The checklist stays a checklist rather than a wall of pickers — which is why the box was small to begin with — but it no longer hides the feature. The button carries its own accessible name, so the task it belongs to is announced.
2. The deadline panel now sits beside every module Overview
Application Tracking, Essays and Financial Aid all get the same panel the dashboard sidebar shows, so "what is actually due" no longer means leaving the module. Fully interactive — ticking and adding dates work from in there.
This required a refactor first, and it is the substance of this PR.
The college list persists as one whole array and had two owners: Application Tracking (
persistApps) and the dashboard's deadline hook. Whichever saved last replaced what the other had just written — the data-loss shape found in #48. The dashboard dodged it withactive: !openModule, pausing the hook whilst a module was open, which is precisely what ruled out rendering the panel inside one.So the list has a single owner now —
ApplicationsContext, wrapped around everything that reads or writes it:Two things deliberately left alone:
3. Discover can narrow by region
"Nearest" only reorders — a student set on the Northeast still got Boston first and Arizona fifth.
The colleges table already carries a region, but it is the four census ones and they are too coarse to browse by: "West" is Seattle, Phoenix and Honolulu together. This adds a finer set derived from the state — New England, Mid-Atlantic, Southeast, Midwest, South Central, Mountain West, Pacific.
The census map is untouched: it is stored on every row and feeds the distance dimension of the match score, so re-cutting it would silently restate every student's results for a UI change.
The student's own region is labelled "(yours)" rather than preselected — someone browsing Discover is often looking for somewhere they are not. The filter also applies to hidden gems, which already avoid leaking an opted-out pathway; an out-of-region gem is the same kind of leak. Territories have no search region, so only an explicit pick ever hides them.
Testing
483 tests pass, lint and typecheck clean, production build runs.
New coverage: the single-owner regression, the refresh-key behaviour, the "+ Add date" flow, the region filter, and that all 50 states and DC land in exactly one region — a missing state would silently vanish from Discover the moment anyone filtered.