Exercise 3: Why This Course Never Needed an ItemsContext-Style Mechanism — Possible Solution
====================================================================

WHY FOOD TRACKER (REACT + EXPRESS) NEEDED ONE
------------------------------
That course's frontend is built as a tree of independent React components (an alerts dashboard, a search box, a recipe suggestions list), each managing its own state with no direct relationship to the others. A single mutation, like marking an item used, needed to reach multiple of these unrelated components at once, and wiring direct calls between every pair would have required editing every mutation site each time a new feature was added - a genuine, growing coordination problem that justified building a shared Context specifically to solve it.

WHY THIS COURSE NEVER RAN INTO THE SAME PROBLEM
------------------------------
This app has no component tree at all - it's a handful of plain functions like loadAlerts() and loadRecipeSuggestions(), directly callable by name from anywhere else in the same JavaScript file. markUsed can simply call both of them directly, since there's no framework-imposed boundary preventing one part of the code from calling another part directly.

WHY THIS TRACES BACK TO CHAPTER 1
------------------------------
Chapter 1 deliberately chose a plain vanilla-JS frontend specifically to keep this course's focus on FastAPI's backend design, rather than pairing FastAPI with React a third time in this quartet. That choice is exactly what avoided ever needing a coordination mechanism like Context in the first place - the problem Context solves only exists once an app is built as a tree of independent, loosely-coupled components, and this app was never built that way to begin with.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains the specific coordination problem Context was built to solve in the Express sibling course, correctly explains why this app's simpler, function-based structure never creates that same problem, and correctly traces the reason back to Chapter 1's own deliberate choice of a vanilla-JS frontend.