Premier League Predictor: Django & MySQL — Chapter 4, Exercise 1
====================================================

TASK
Explain why fixture_entry never needs a JavaScript fetch call just to
display the initial 20 team buttons, tracing the reason back to what
Django's template engine does that plpredict-fastapi1's own vanilla-JS
frontend has no equivalent for.

SOLUTION

plpredict-fastapi1's own frontend is a static HTML file served
unchanged for every request — FastAPI's StaticFiles has no way to
insert dynamic, per-request data (like the current season's own 20
teams) into that file before it reaches the browser. The only place
that data can be added is after the page has already loaded, via
JavaScript making a real fetch() call to a separate JSON route and
building the button elements from the response.

Django's own fixture_entry view is completely different in kind: it's
a real Python function that runs fresh on every request, queries the
real SeasonTeam rows for the gameweek's own season, and passes that
real data into render(), which uses Django's template engine to
produce a genuinely new HTML document for that specific request. The
{% for team in teams %} tag inside fixture_entry.html runs on the
server, before the response is ever sent to the browser — by the time
the HTML actually arrives, every one of the 20 <button> elements
already exists in the markup, populated with real data.

That's the real underlying difference: FastAPI's static-file approach
has no server-side templating step at all, so populating dynamic
content has to happen client-side after the fact; Django's own
render-a-template-per-request model does that population server-side,
as a completely ordinary part of generating the response — making a
separate client-side fetch just to build the same button grid
genuinely redundant here.

WHY THIS WORKS AS AN ANSWER
----------------------------
It correctly identifies the real structural reason FastAPI's own
static-file frontend has no choice but to fetch data client-side (no
server-side templating step exists for it), and contrasts that
precisely with what Django's render()/template-tag mechanism already
does automatically on every request.