Files
school_compare/nextjs-app
TudorandClaude Opus 5.5 4e4b30e812
PR Checks / Frontend Typecheck + Tests (pull_request) Successful in 1m14s
PR Checks / Backend Smoke (pull_request) Successful in 10s
PR Checks / Build Backend (no push) (pull_request) Successful in 19s
PR Checks / Build Frontend (no push) (pull_request) Successful in 1m20s
PR Checks / Build Pipeline (no push) (pull_request) Successful in 11s
PR Checks / AI Code Review (Claude) (pull_request) Successful in 26s
feat(search): align the map view with the mockup and open it on desktop
The map view now follows option B of the results-controls mockups:

- The list sits in a pane on the left, under the result count and sort,
  and the map fills the rest of the screen below the pinned toolbar. The
  toolbar's height is measured, so the split ends 1rem above the bottom
  of the screen however the controls wrap.
- Pins are brand-teal dots and the selected one is coral. The search
  location is an ink dot, the search radius a dashed circle with its
  distance, and the view fits that circle. Tiles are muted and the zoom
  sits under the fullscreen button.
- A school picked on the map or in the list opens a card on the map
  (View, + Compare, following the basket), and its list card is ringed
  and scrolled into view. Phones keep the bottom sheet.
- The list cards show the full name, Ofsted and school type, the
  headline figure and pupils.

The map cards now follow the list rows: no England benchmark for
special schools, PRUs and AP, and no placeholder all-zero RWM (Greenmead
showed "0% RWM -62 pts vs national"). That rule moves to a shared
listRwmValue helper.

A postcode search opens on the map for desktop browsers, chosen on the
server from the user agent so the list never paints first. The client
falls back to the list below 1024px, and follows the default through
client-side navigation from the hero until the reader picks a view.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-30 21:30:33 +01:00
..

SchoolCompare frontend and CMS

Next.js App Router with React, TypeScript, CSS Modules, Chart.js, Leaflet and Payload CMS. It serves school search, comparisons, rankings, school/place detail pages and editorial content across England.

Start with the repository overview, architecture and development checks.

Source map

Path Purpose
app/(frontend)/ Public root layout, server pages and FastAPI proxy
app/(payload)/ Payload root layout, /admin and /cms-api
app/robots.ts, app/opengraph-image.tsx, root icons Site-wide metadata endpoints
components/ Client views and reusable display components
components/school/ School detail sections
lib/api.ts, lib/types.ts Fetch wrappers and manual school API types
lib/schoolSections.ts, lib/compareLogic.ts Presentation decisions and data preparation
context/, hooks/ Comparison state, suggestion state and responsive behaviour
collections/, blocks/, migrations/ CMS schema and production migrations
__tests__/ Jest and React Testing Library tests

Do not introduce a shared app/layout.tsx: public pages and Payload have separate root layouts. Keep root metadata files outside the route groups.

Data and state

Server pages fetch initial data directly from FASTAPI_URL. Browser fetches use /api by default, forwarded by app/(frontend)/api/[...path]/route.ts. FASTAPI_URL must include /api. See .env.example for CMS and API settings.

State uses React hooks/context, URL search parameters and localStorage for the comparison basket. SWR is not installed. Maps use dynamic Leaflet wrappers. Revalidation intervals are configured in fetch wrappers and pages; they vary by resource. Backend reloads do not automatically invalidate every Next.js cache.

Commands

npm ci
npm run typecheck
npm test -- --runInBand
npm run build

test:watch and test:coverage are also available. There is no lint script. A running application needs the backend/data environment described in the development guide.

After CMS field or editor changes, run npm run generate:importmap. Keep payload-types.ts generated from the CMS schema rather than editing it by hand. The build must work without a database connection; avoid module-scope CMS queries and DB-backed generateStaticParams functions.

See publishing for CMS operations and deployment for staging and production promotion.