Form calendar: repaint it when Max correspondances (and the other filters) change - #64
Merged
Merged
Conversation
…ters) change The Trip tab's "When to leave?" calendar is derived from the whole form — readQueryFromForm() feeds odConnOptsFor / getawayOptsFor / filterOptsFor — but only the origin and destination fields were wired to repaint it. Changing "Max correspondances", the control sitting directly beneath it, left the previous month on screen: days that the new connection budget had just opened up stayed grey until the route was retyped. Wire every control the grid actually depends on to the repaint: max connections, the via hub, depart-after / depart-before / arrive-before, the max-duration cap, the train type, night trains + only-night, overnight stopovers, and the same-day minimum time on site. Typed fields (via, max duration) debounce like the route fields; the rest repaint on the next frame so the control's own update paints first (deferFormCalRepaint, factored out of the origin/destination handler). This only repaints the calendar — the filters stay staged, and the results still wait for Search, as before.
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
2 participants
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.
The bug
Changing Max correspondances left the Trip tab's "When to leave?" calendar untouched — the month sitting directly above the control kept the old colours, greyed on the very days the new connection budget had just opened up.
The calendar is derived from the whole form (
repaintFormCalendar→readQueryFromForm()→odConnOptsFor/getawayOptsFor/filterOptsFor), but only the origin and destination inputs were wired to repaint it, so every other filter it depends on silently left a stale grid behind.The fix
Wire each control the grid actually depends on to the repaint:
deferFormCalRepaint, factored out of the existing origin/destination handler.Filters stay staged: this only repaints the calendar, the results still wait for Search (the existing "stages a field change" test and the
edits stay staged until SearchE2E scenario both still pass).Verification
tests/app.smoke.test.ts: Paris → Toulouse withconn=0has no possible day (the one direct train isn't a free-MAX seat); raising the select to 1 change greens up the via-Bordeaux day immediately, and the results only follow on Search. It fails onmainand passes here.dist, committed data snapshot), Paris origin-only: per-day destination counts go 1660 → 1820 when allowing 2 changes, live on the select'schange.tsc --noEmit,npm test(151 passed),npm run build,npm run test:e2e(14/14).docs/user-flows.mdupdated to describe what the calendar recomputes on.Generated by Claude Code