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

TASK
Explain what define:vars forcing is:inline actually changes about
how a script is processed, and why that made data-* attributes the
safer choice for this specific page given Chapter 4's own established
addEventListener discipline.

SOLUTION

Normally, a plain <script> tag written directly inside an Astro
page's own template gets processed by Astro's build pipeline: it's
bundled into a real, separate file, deduplicated if the same script
would otherwise appear more than once, and treated as a genuine ES
module. That processing is exactly why Chapter 4 found that a
function declared at the top level of the script is never attached
to the global window object — module scope keeps it private to that
module, unlike a classic, unprocessed script's own global scope.

Adding define:vars to a <script> tag changes that processing
entirely, because — checked directly against Astro's own directives
reference — it automatically implies the is:inline directive. An
is:inline script is rendered into the final HTML output exactly as
it was written in the source file: it isn't bundled into a separate
file, it isn't deduplicated, and none of its own import statements
get resolved by Astro at all. Astro's own documentation is explicit
that, for scripts specifically, it recommends passing variables
manually instead of using define:vars, precisely because of this
tradeoff.

That distinction matters directly for this page because of what
Chapter 4 already established: the entire reason inline onclick
attributes fail on this course's own scripts is that a processed,
bundled script runs as a module, and a module's top-level functions
aren't global. An is:inline script is documented to skip that
processing — it's rendered exactly as authored, which is a real,
different code path from the module treatment every other chapter's
own script relies on. Reaching for define:vars here would put this
one specific page's script on a genuinely different, less-bundled
processing path than every other script in the course, right at the
exact page where getting that distinction wrong would be easiest to
miss, since nothing about the resulting page would look obviously
broken — it would just be quietly inconsistent with how every other
chapter's own script gets treated.

data-* attributes avoid the question completely: the script tag has
no define:vars on it, so it keeps going through Astro's own normal
bundling/module pipeline exactly like every prior chapter's script,
and the server-resolved values (seasonId, gameweekId, the team list,
usedTeamIds) are simply read out of the DOM via element.dataset
inside that already-normally-processed module — the same way any
client-side code reads data a server has already rendered into HTML,
with no special-cased script-processing behavior involved anywhere.

WHY THIS WORKS AS AN ANSWER
----------------------------
It correctly states what is:inline actually changes (no bundling, no
deduplication, no import resolution — rendered exactly as authored),
ties that directly back to Chapter 4's own module-vs-global-scope
finding to explain the real risk, and explains precisely why data-*
attributes sidestep the issue by keeping the script on the same,
normal processing path as every other chapter's own script.