The search results toolbar switched between one line and two depending on whether the search had results. It now depends only on the window width:
≥ 1340px: always one line.
641–1339px: always two lines — search (and the List/Map switch) on line 1, the filter chips on a full-width line 2.
≤ 640px (phones): unchanged.
Why
The toolbar wrapped wherever it ran out of room, and its contents change with the results: the List/Map switch (~186px) only appears when there are results. So the same search folded onto two lines with results and sat on one without.
How
FilterBar.module.css: the controls row no longer wraps away from the search on wide screens. The search section takes what is left (flex: 1 1 0). 1340px is where the fullest toolbar (distance, phase, type, More filters, Clear, switch) still leaves the search box 12rem. Phase/type chips cap at 11rem (was 14rem) to fit; long values already truncate with an ellipsis.
Between 641 and 1339px the controls row takes flex-basis: 100%, so it always sits on its own line.
The List/Map switch moves into FilterBar's row via a new viewSwitch prop. Beside the bar, it stopped line 2 short, so around 1000px the chips spilled onto a third line with results but not without — the same flip-flop.
Verification
Exact CSS injected on staging and measured with the fullest toolbar: one line at 1400px (search box 256px) and 1340px (192px); two lines at 1339px and 1000px (was three at 1000px).
Jest: 519 passed (two tests that mocked FilterBar now render the switch slot); tsc clean.
New E2E journey: the results toolbar keeps its line count whether or not there are results — same postcode with and without results, at 1400px and 1100px. Run against current staging it fails as expected (2 lines at 1400px with results).
Not yet checked: the MOBILE.md phone widths (360/390/430). Phone CSS is effectively unchanged (the new slot is hidden there, as the switch already was), but this needs the staging deploy.
## What
The search results toolbar switched between one line and two depending on whether the search had results. It now depends only on the window width:
- **≥ 1340px:** always one line.
- **641–1339px:** always two lines — search (and the List/Map switch) on line 1, the filter chips on a full-width line 2.
- **≤ 640px (phones):** unchanged.
## Why
The toolbar wrapped wherever it ran out of room, and its contents change with the results: the List/Map switch (~186px) only appears when there are results. So the same search folded onto two lines with results and sat on one without.
## How
- `FilterBar.module.css`: the controls row no longer wraps away from the search on wide screens. The search section takes what is left (`flex: 1 1 0`). 1340px is where the fullest toolbar (distance, phase, type, More filters, Clear, switch) still leaves the search box 12rem. Phase/type chips cap at 11rem (was 14rem) to fit; long values already truncate with an ellipsis.
- Between 641 and 1339px the controls row takes `flex-basis: 100%`, so it always sits on its own line.
- The List/Map switch moves into FilterBar's row via a new `viewSwitch` prop. Beside the bar, it stopped line 2 short, so around 1000px the chips spilled onto a third line with results but not without — the same flip-flop.
## Verification
- Exact CSS injected on staging and measured with the fullest toolbar: one line at 1400px (search box 256px) and 1340px (192px); two lines at 1339px and 1000px (was three at 1000px).
- Jest: 519 passed (two tests that mocked `FilterBar` now render the switch slot); `tsc` clean.
- New E2E journey: *the results toolbar keeps its line count whether or not there are results* — same postcode with and without results, at 1400px and 1100px. Run against current staging it **fails** as expected (2 lines at 1400px with results).
- Not yet checked: the MOBILE.md phone widths (360/390/430). Phone CSS is effectively unchanged (the new slot is hidden there, as the switch already was), but this needs the staging deploy.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The results toolbar wrapped wherever it ran out of room, and the List/Map
switch only appears when there are results, so the same search took two
lines with results and one without.
From 1340px the controls never wrap away from the search, which takes
what they leave (at least 12rem); phase and type chips cap at 11rem to
fit. Between 641px and 1339px the controls always take a full line of
their own. The switch now sits in FilterBar's row via a viewSwitch slot,
so that line runs the full width instead of stopping short of it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The List/Map switch moves into FilterBar's own row, and CSS now sets the toolbar's line count by screen width (one line from 1340px, two below). The switch no longer changes it. The e2e test and the Jest mocks are updated to match. I found no correctness, security or deploy problems.
🟡 Minor
nextjs-app/components/FilterBar.module.css: The unconditional .filterBar:not(.heroMode) .controlsRow { flex: 0 0 auto; flex-wrap: nowrap; } also applies at phone widths (≤640px) unless the phone block overrides it. Check that the existing phone horizontal-scroll rules still win on specificity and source order. The 1340px breakpoint and the 11rem select cap are hardcoded to the current control set, so adding a control later will silently break the one-line budget.
e2e/tests/journeys.spec.ts: The test infers the line count from bounding boxes, and the 'without results' case relies on school_type=no-such-type returning an empty result. That could instead trigger a validation error or ignore the unknown filter, which would make the test flaky or vacuous. The viewport widths 1400 and 1100 sit well clear of the 1340px breakpoint, so the thresholds are fine.
## 🤖 AI Code Review (Claude Code)
The List/Map switch moves into FilterBar's own row, and CSS now sets the toolbar's line count by screen width (one line from 1340px, two below). The switch no longer changes it. The e2e test and the Jest mocks are updated to match. I found no correctness, security or deploy problems.
### 🟡 Minor
- **nextjs-app/components/FilterBar.module.css**: The unconditional `.filterBar:not(.heroMode) .controlsRow { flex: 0 0 auto; flex-wrap: nowrap; }` also applies at phone widths (≤640px) unless the phone block overrides it. Check that the existing phone horizontal-scroll rules still win on specificity and source order. The 1340px breakpoint and the 11rem select cap are hardcoded to the current control set, so adding a control later will silently break the one-line budget.
- **e2e/tests/journeys.spec.ts**: The test infers the line count from bounding boxes, and the 'without results' case relies on `school_type=no-such-type` returning an empty result. That could instead trigger a validation error or ignore the unknown filter, which would make the test flaky or vacuous. The viewport widths 1400 and 1100 sit well clear of the 1340px breakpoint, so the thresholds are fine.
tudor
merged commit e9886361d2 into main2026-10-01 15:06:31 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What
The search results toolbar switched between one line and two depending on whether the search had results. It now depends only on the window width:
Why
The toolbar wrapped wherever it ran out of room, and its contents change with the results: the List/Map switch (~186px) only appears when there are results. So the same search folded onto two lines with results and sat on one without.
How
FilterBar.module.css: the controls row no longer wraps away from the search on wide screens. The search section takes what is left (flex: 1 1 0). 1340px is where the fullest toolbar (distance, phase, type, More filters, Clear, switch) still leaves the search box 12rem. Phase/type chips cap at 11rem (was 14rem) to fit; long values already truncate with an ellipsis.flex-basis: 100%, so it always sits on its own line.viewSwitchprop. Beside the bar, it stopped line 2 short, so around 1000px the chips spilled onto a third line with results but not without — the same flip-flop.Verification
FilterBarnow render the switch slot);tscclean.🤖 Generated with Claude Code
🤖 AI Code Review (Claude Code)
The List/Map switch moves into FilterBar's own row, and CSS now sets the toolbar's line count by screen width (one line from 1340px, two below). The switch no longer changes it. The e2e test and the Jest mocks are updated to match. I found no correctness, security or deploy problems.
🟡 Minor
.filterBar:not(.heroMode) .controlsRow { flex: 0 0 auto; flex-wrap: nowrap; }also applies at phone widths (≤640px) unless the phone block overrides it. Check that the existing phone horizontal-scroll rules still win on specificity and source order. The 1340px breakpoint and the 11rem select cap are hardcoded to the current control set, so adding a control later will silently break the one-line budget.school_type=no-such-typereturning an empty result. That could instead trigger a validation error or ignore the unknown filter, which would make the test flaky or vacuous. The viewport widths 1400 and 1100 sit well clear of the 1340px breakpoint, so the thresholds are fine.