Premier League Predictor: Astro — Chapter 10, Exercise 3
====================================================

TASK
Build the real dynamic fixtures route yourself, visit it for a
gameweek that already has two fixtures entered, and confirm both
teams already involved show as disabled the moment the page first
loads — with no click required to discover it. Then visit
/help/scoring and, using your browser's own dev tools, confirm the
page's response has no per-request dynamic content by comparing two
separate requests.

SOLUTION

Steps to complete the hands-on part (dynamic route):

1. Create src/pages/admin/seasons/[seasonId]/gameweeks/[gameweekNumber]/fixtures.astro
   exactly as shown in the chapter, and src/pages/help/scoring.astro
   with export const prerender = true.
2. Using existing routes, create a season with 20 teams and gameweek
   1, then add two real fixtures to it (e.g. Team A vs. Team B, Team
   C vs. Team D) via Chapter 4's own POST /api/gameweeks/{id}/fixtures
   route.
3. Visit /admin/seasons/{seasonId}/gameweeks/1/fixtures directly in a
   browser.
4. Confirm Team A, Team B, Team C, and Team D's own buttons in the
   team grid are already rendered with the disabled attribute present
   — inspect the actual DOM (not just visually, since a disabled
   button can look similar to an enabled one depending on styling) to
   confirm the four buttons genuinely carry disabled, while every
   other team's own button does not. This should be true immediately
   on page load, with zero clicks performed and no visible flash of
   an enabled button before it disables itself.

Written confirmation: because usedTeamIds is computed server-side in
the page's own frontmatter before any HTML is sent, and the team-grid
building loop checks usedTeamIds.has(team.id) while creating each
button (not afterward), there is no moment at which an already-used
team's button is ever rendered as clickable — unlike Chapter 4's own
version, which always started with an empty set and only disabled
buttons in response to a later, successful fixture submission.

Steps to complete the hands-on part (prerender check):

5. Run a production build (npm run build) followed by the production
   server, so prerendering actually takes effect (dev mode may
   re-render on every request regardless of the prerender flag).
6. Open browser dev tools, go to the Network tab, and load
   /help/scoring twice, a few seconds apart. Compare the two
   responses: identical byte-for-byte HTML, and — depending on the
   deployment adapter — a response that may not even require the
   server-rendering code path to run a second time at all, since the
   page was generated once at build time rather than computed fresh
   per request.
7. As a contrast, load /admin/seasons/{seasonId}/gameweeks/1/fixtures
   twice in a row after adding a third fixture between the two loads.
   Confirm the second response's own team grid reflects the newly
   disabled team, proving this page really is recomputed per request
   — the opposite of /help/scoring's own frozen-at-build-time content.

WHY THIS WORKS AS AN ANSWER
----------------------------
It completes both real, hands-on checks — confirming the dynamic
route's own already-correct disabled state on first render with no
click needed, and confirming /help/scoring's own genuinely static,
identical-across-requests output via a direct two-request comparison
— and explicitly contrasts the static page against the dynamic
fixtures page reflecting a real, freshly-added fixture, making the
prerender-vs-on-demand distinction concrete rather than asserted.