Premier League Predictor: FastAPI & PostgreSQL — Chapter 10, Exercise 1
====================================================

TASK
Explain why selector.js broadcasts a single CustomEvent rather than
exporting getSelectedSeasonId()/getSelectedGameweekId() functions for
other scripts to call, and name one other place in this course where a
similar decoupling choice was already made.

SOLUTION

If selector.js only exported getter functions, every other script that
needs the current season/gameweek — fixtures.js, predictions.js, both
table scripts — would need to know not just that those functions exist,
but exactly WHEN to call them. A page loaded before the user finishes
picking a season would get a stale or null value from those getters,
and each page would need its own logic to detect "the selection
changed, go re-fetch the getters again" — logic that would end up
duplicated across every single page that cares about the selection.

Broadcasting a selection-changed CustomEvent inverts that relationship:
selector.js doesn't need to know what else exists on the page or when
those other scripts want fresh data — it just announces "the selection
changed, here's the new season and gameweek" the moment it actually
happens, and any script that cares simply registers one event listener
and reacts. Nothing in selector.js needs to change if a new page is
added later that also wants to listen; nothing in fixtures.js needs to
poll or guess when to re-check the selection.

A similar decoupling choice already appears in Chapter 7: instead of
Chapter 9's rollover route re-deriving its own league-standings logic
independently, it reuses compute_league_table() directly — Chapter 9
doesn't need to know how the league table query works internally, only
that calling that one function gives it the real, current standings.
Both cases share the same underlying idea: one piece of code owns a
piece of state or logic, and everything else interacts with it through
one narrow, well-defined interface (a function call, or an event)
rather than reaching into its internals.

WHY THIS WORKS AS AN ANSWER
----------------------------
It explains the concrete coupling problem a getter-function approach
would create (every consumer needing to know the right timing), states
what the event-based approach actually decouples, and correctly
identifies a genuine prior instance of the same underlying design
principle already used in this course's own backend.