Premier League Predictor: Astro — Chapter 9, Exercise 1
====================================================

TASK
Explain why this chapter needs no refactoring step to reuse Chapter
7's own league-table logic, and contrast that directly with what the
FastAPI and Django sibling courses had to do at this exact point in
their own Chapter 9s.

SOLUTION

Both sibling courses originally wrote their own version of the real
league-table query directly inside a single API route/view function
in their own Chapter 7 — the SQL (or ORM equivalent) that computes
points, goal difference, and won/drawn/lost lived only inside that
one route's own handler code, with no separate, importable function
wrapping it. When their own Chapter 9 needed the identical
computation a second time — to find the real bottom three teams for
relegation — that logic had to be pulled out of the original route
and rewritten as a standalone, reusable function (compute_league_table()
in both cases) before it could be called from a second place at all.
That extraction is itself a real, deliberate refactoring step, done
specifically because the earlier chapter never anticipated needing
the same logic twice.

This course's own Chapter 7 never made that mistake to begin with:
getLeagueTable() was written into its own separate module,
src/lib/leagueTable.ts, from the very first draft of that chapter —
with an explicit tip-box at the time naming Chapter 9's own future
reuse as the exact reason for splitting it out rather than writing it
inline inside the GET /api/seasons/{id}/table route handler. Because
of that earlier decision, this chapter's own getRelegated() and
getSurvivors() functions can simply import getLeagueTable() and call
it directly, with zero changes made to Chapter 7's own file at all.

The real contrast, then, isn't that this course's SQL is somehow
better — it's that Chapter 7 was written with the knowledge that this
exact function would be needed again, and structured accordingly,
while both sibling courses' own Chapter 7s were written to answer
only the immediate question in front of them at the time.

WHY THIS WORKS AS AN ANSWER
----------------------------
It correctly identifies that both sibling courses' own Chapter 7
implementations lived inline inside a single route/view and had to be
genuinely extracted into a reusable function once Chapter 9 needed
them again, and explains precisely why this course avoided that step
entirely — a deliberate, earlier architectural decision, not a
coincidence or a claim that the underlying computation is simpler.