The async + data foundation that turns a static card into a live app
2026-10-14
Session 1 gave you a static review card: HTML for the structure, CSS for the styling. It renders, but it is a picture — no data comes in, nothing reacts, the values are hard-coded.
This session (Session 2) hands you the JavaScript you need to make that card live:
You are not being made a JavaScript expert. You are getting just enough to walk into Session 3 — where the card becomes a real React component fed with sample data — and to verify the JavaScript an AI assistant generates.
The three-sentence version
fetch API.then() promise chainsPromise.all / Promise.raceThis whole section is a refresher, not a re-teach. If the syntax is already familiar, skip straight to the async core below. If you are new to JavaScript, expand only what you need. Everything here will show up in the mandatory core.
Variables. Default to const; use let only when you must reassign; never var.
Arrow functions. Short callbacks; implicit return when there is no body.
Template literals. Backticks + ${} for interpolation and multi-line strings. (JSX uses the same idea.)
Objects are key/value pairs; read them with dot notation (like a PHP assoc array, but . not ->).
Arrays are ordered lists; .map transforms, .filter selects.
Destructuring pulls values out without writing the index or key.
Spread / rest (...) copies elements or properties.
You will recognize these more than write them from scratch:
// reduce — fold a list into one value (e.g. a total)
const total = prices.reduce((sum, p) => sum + p, 0);
// find / some / every — ask a question about the list
const free = products.find((p) => p.price === 0);
const hasFiveStar = reviews.some((r) => r.rating === 5);
const allVerified = reviews.every((r) => r.verified_purchase);
// optional chaining (?.) — stop at the first missing link instead of crashing
const headline = review?.title; // review not loaded yet? undefined, not a crash
// nullish coalescing (??) — default only for null/undefined (not for 0 or "")
const label = product.name ?? "Unknown";fetchThis is the heart of the session. Everything here is mandatory and written in full — no part of it is hidden.
In Session 1 your card was a picture: the values were hard-coded in the HTML. Now the values come from a JSON data file you fetch. But a network request takes time — maybe 50 ms, maybe 2 s. Your JavaScript starts running before the data arrives.
That mismatch is what asynchronous code is all about: “keep going, and here’s what to do the moment the data shows up.”
Analogy. In a coffee shop you either order and stand there waiting, or you order, get a number, and keep reading your phone until the barista calls it. A blocking program behaves like the first; an async program behaves like the second.
You do not need the internals. You need one mental model:
That is why you can await a fetch without freezing the page — and why a missing await silently does something surprising (see the verify checklist in Section 6).
fetch, setTimeout, etc. live here; they run outside JS and call back when done.Promise callbacks run here and are drained before the next macrotask — which is why promise resolution feels “immediate” once it happens.A Promise is an object that stands in for a value that isn’t ready yet. It is in one of three states:
The key insight: fetch(url) gives you a Promise, not the data. You must “unwrap” it.
async / await: making async read top-to-bottomawait only works inside an async function. It says: “pause here until this Promise settles, then hand me the result.” Wrap the body in try/catch to handle failures.
async function loadProducts() {
try {
const response = await fetch("http://localhost:4000/api/products"); // pause until the request settles
const body = await response.json(); // pause until the JSON is parsed
return body;
} catch (err) {
console.error("Could not load products:", err);
return []; // fall back to an empty list so the UI can still render
}
}Three moving parts, every time:
| Part | Where | Job |
|---|---|---|
async |
on the function | lets you use await inside |
await |
before each Promise | pauses until it settles, returns the value |
try/catch |
around the awaits | catches network errors & thrown errors |
Promise.all) when you have several requests
If you need two things at once (say products and categories), you can run them in parallel and await the results together:
useEffect (Session 3) shows you the idiomatic place to fire a request. It is here so the term is not a surprise.
fetch API, step by stepA GET request is three steps:
const response = await fetch(url) — send the request, get a Response object.response.ok is true for 2xx; a failed request does not throw, so you must check.const body = await response.json() — parse the JSON body into a JS value.Why the status check matters.
fetchonly rejects on a network failure (offline, bad URL, CORS block). An HTTP 404 or 500 still resolves — the status lives on theResponse. Skippingresponse.okis one of the most common real-world bugs.
:4000 (mirrors the app)Here is the exact shape of the pattern you will see everywhere in the app. The backend API runs on port 4000; the app calls it with a base URL (see the next section for where that base comes from).
// BASE: the backend origin. In the app this is VITE_BACKEND_URL, default http://localhost:4000
const backend = "http://localhost:4000";
async function loadProducts() {
try {
// 1. request
const response = await fetch(`${backend}/api/products`);
// 2. status check (a 404/500 does NOT throw by itself)
if (!response.ok) {
throw new Error(`Products request failed: HTTP ${response.status}`);
}
// 3. parse JSON
const body = await response.json();
// 4. the app returns { data: [...], meta: {...} } — we want the list
const products = body.data || [];
return products;
} catch (err) {
console.error("Failed to load products:", err);
return []; // graceful fallback: the UI renders "no products"
}
}What to notice (this is the whole async story):
async,await the fetch and the response.json(),response.ok before parsing,try/catch turns a failure into a clean empty list instead of a crash.You now know the pattern in the abstract. Here is the actual code from the app this course builds against — fullstack-minimal-app (the develop branch of ebpro/fullstack-minimal-app, referenced by URL, not a submodule). The frontend runs on :5173 and the backend API on :4000.
The frontend calls the backend with a base URL read from the env var VITE_BACKEND_URL, which defaults to http://localhost:4000. In the component we look at, that base is handed in as a prop named backend, so every request is built as `${backend}/api/...`.
flowchart LR
UI["React UI<br/>(:5173)"]
F["fetch() + async/await"]
API["Express API<br/>(:4000)<br/>GET /api/products"]
UI -->|"1. component mounts"| F
F -->|"2. HTTP request"| API
API -->|"3. { data, meta }"| F
F -->|"4. setState -> re-render"| UI
frontend/src/components/ProductList.jsx)This is the heart of the component — everything else around it is UI:
const fetchPage = useCallback(async (p = page, c = categoryFilter) => {
setLoading(true)
try {
const params = new globalThis.URLSearchParams({ page: String(p), per_page: String(perPage) })
if (c) params.set('category_id', c)
const res = await fetch(`${backend}/api/products?${params.toString()}`) // 1. request
const body = await res.json() // 2. parse JSON
setProducts(body.data || []) // 3. -> state
setMeta(body.meta || { total: 0, page: p, per_page: perPage, total_pages: 1 })
} catch (err) {
console.error('Fetch page failed', err) // 4. error handled
} finally {
setLoading(false) // 5. stop the spinner
}
}, [backend, page, categoryFilter, perPage])
globalThis.just points at the browser’s global scope — read it as plainURLSearchParams.
Line by line — this is exactly Section 3, in the wild:
async + await fetch(...) + await res.json() → the three-part pattern.URLSearchParams builds the query string ?page=2&per_page=9&category_id=3.{ data: [...], meta: {...} }; the component keeps data (the list) and meta (pagination info) in state with setProducts / setMeta.try / catch / finally — the error is logged, and the finally always turns off the loading flag so the UI can never get stuck on a spinner.Note:
useState,useEffect,useCallbackandsetProducts(...)are React features — they are why the next section exists. The fetch/async half of this snippet is pure JavaScript you already know.
The component guards the edge cases early, then renders the list with .map:
Two things to notice:
categories is a prop — it is fetched the same way (fetch → res.json()) higher up in the app and passed down. Same pattern, different endpoint.setProducts runs, the list re-renders. No manual DOM updates — which is precisely the problem React solves.You can build everything in Session 3 with plain JavaScript. For a static card, you already did (Session 1). So why reach for a framework at all? Because once data flows and the UI has to stay in sync with it, the manual approach falls over. Here is the honest version of why.
Imagine your card now shows a list of reviews fetched from the backend, and the user can add, filter, and sort them. In plain JavaScript you own every pixel:
// 1. MANUALLY update the DOM whenever data changes
const list = document.querySelector("#reviews");
list.textContent = "";
reviews.forEach((r) => {
const el = document.createElement("li");
el.textContent = `${r.author}: ${r.comment}`;
list.appendChild(el);
});
// 2. KEEP STATE IN SYNC — you track it by hand in variables
let isLoading = false;
let error = null;
// ...and you must remember to update the DOM every single time one of these changes.
// 3. ASYNC COMPLEXITY — where do you fetch? when? after what?
button.addEventListener("click", async () => {
isLoading = true; // update the spinner in the DOM
const res = await fetch(url);
const data = await res.json();
reviews = data; // now go update the DOM again…
isLoading = false; // …and the spinner again…
});
// 4. BOILERPLATE — select, create, append, remove, re-listen for events, over and over.The failure mode is not any one bug — it is that state lives in your variables and the screen lives in the DOM, and nothing keeps the two honest with each other. Add filtering, then sorting, then a shopping cart, and every new feature means “find the right element and update it by hand.” The code does not just get longer; it gets fragile.
React inverts the model. Instead of “tell me how to change the screen step by step,” you describe what the screen looks like for a given state, and React updates the real DOM for you:
The mental shift:
useState). Change state → React re-renders the component.createElement, no appendChild, no textContent =.onClick, .map, if).That single idea — UI = f(state) — is what Session 3 builds on.
React keeps a lightweight in-memory copy of the UI — the virtual DOM. When state changes, it compares the new tree to the previous one and writes only the minimal set of changes to the real DOM. You do not need to understand the diffing algorithm; you only need the consequence: you describe the target state, React computes the cheapest path to it.
Scope check. We are not going to build a virtual DOM, nor to benchmark React against vanilla. We are adopting its model because it removes the sync bug class from Section 5.1.
This is the uniform beat of the course: Concept → AI generates → You verify → You integrate. For this session the AI beat targets JS/async code, so the verify checklist is about the failure modes below.
We are going to have the assistant write a small, real piece of the app: fetch the categories and make them available to render. You already know the shape — this is the categories sibling of the products fetch from Section 4.
Send the assistant a CRISP prompt — Context, Role, Input, Steps, Parameters:
Context: We're in the fullstack-minimal-app frontend (React + Vite, :5173). The backend API is on
:4000, reached via the VITE_BACKEND_URL base URL (default http://localhost:4000).
Role: You are a senior frontend developer writing clean, modern JavaScript.
Input: An endpoint `${backend}/api/categories` that returns { data: [{ id, name }, ...] }.
Steps: 1) Write an async function loadCategories(backend) that fetches that URL.
2) If !response.ok, throw new Error(`HTTP ${response.status}`).
3) Parse JSON and return body.data || [].
4) Wrap the body in try/catch; on error, console.error and return [].
5) Return data only — do NOT build any HTML or touch the DOM.
Parameters: Pass `backend` in as an argument (do not hardcode the URL). No external libraries.
Use const, arrow functions, and template literals.Expected output (what you should see):
Do not paste the output into the app until it passes every line of this checklist:
| # | Failure mode | What to check |
|---|---|---|
| 1 | Missing await |
const res = fetch(url) then res.json() with no await → res is a Promise, not data. Every fetch and every res.json() is awaited, and the enclosing function is async. |
| 2 | No try/catch |
Network errors crash silently. The async body is wrapped; the error is handled (log + graceful fallback, e.g. return []). |
| 3 | Unhandled Promise rejection | A fire-and-forget fetch or a .then chain with no catch. Every Promise has a handler; no floating await sits outside a try. |
| 4 | response.ok skipped / CORS assumed |
A 404/500 does not throw, and res.json() on an error body can throw or parse garbage. The status is checked before parsing. Also: the request is cross-origin (:5173 → :4000) — CORS is a backend concern (Session 4). Flag it; never paper over it client-side. |
| 5 | Callback nesting / callback hell | Nested .then().then().then() instead of async/await. The flow reads top-to-bottom. |
| 6 | innerHTML for dynamic content (XSS) |
AI loves el.innerHTML = data — that executes injected HTML/script. React auto-escapes {value} in JSX, so prefer returning data + JSX over string-building with innerHTML. Only ever set innerHTML with fully trusted, static content. |
If any line fails, send the assistant the specific failing line and a one-sentence correction — do not rewrite the whole thing by hand.
Once the code passes the checklist:
:5173) and the backend (:4000); confirm the categories actually appear — not a spinner, not a red error.catch fires, you see a clean message, not a blank page).The commit is your checkpoint: if the next step (wiring it into a component in Session 3) goes wrong, you can return to a known-good state.
Keep these on hand. Swap the … values for the task at hand. Each follows CRISP (Context, Role, Input, Steps, Parameters).
Context: fullstack-minimal-app frontend (React + Vite, :5173); backend on :4000 via VITE_BACKEND_URL.
Role: Senior frontend developer, modern JS.
Input: Endpoint `${backend}/api/…` returning { data: [...] }.
Steps: 1) async fn load…(backend) -> fetch(url)
2) if (!res.ok) throw new Error(`HTTP ${res.status}`)
3) const body = await res.json(); return body.data || []
4) wrap in try/catch; on error, console.error + return []
Parameters: pass `backend` in as an argument (no hardcoding); no libraries; const + arrow + template
literals; return data only — no DOM, no innerHTML.Context: The component already fetches `…`; it has no loading or error state.
Role: Senior frontend developer.
Input: The current fetch code + the state variables available.
Steps: 1) add a `loading` flag: true before the request, false in `finally`
2) add an `error` state: set it in `catch`
3) return early in the render for loading and for error
4) never leave the spinner stuck (always `finally`)
Parameters: keep the existing data shape; do not change the endpoint; minimal diff..then chains to async/awaitContext: This snippet uses nested .then() / callbacks and is hard to read.
Role: Senior frontend developer, clean modern JS.
Input: The existing snippet (paste it).
Steps: 1) convert to an async function with await at each step
2) keep the same behavior (same requests, same result)
3) add try/catch around the awaits
4) no behavior change — a pure readability refactor
Parameters: same function name and return value; no new dependencies.const/let, arrow functions, template literals, destructuring, spread, and map/filter show up constantly; recognize them, do not recite them.fetch(url) returns a Promise, not data — you await it, then await response.json(), and you check response.ok before parsing (a 404/500 does not throw).async + await + try/catch is the whole async story you need — it makes asynchronous code read top-to-bottom and handles failures gracefully (log + fallback).${backend}/api/products → parse { data, meta } → setProducts(...); the async half is plain JS, the state half is React.await, no try/catch, unhandled rejection, skipped response.ok / CORS assumption, callback nesting, and innerHTML for dynamic content (XSS — React auto-escapes instead).E. Bruno - JavaScript for React