Saved on the server

The ♥ moves from localStorage to the server, so it no longer lives in one browser. (The course server keeps one list per market, so per student; a real one would keep one per signed-in user.) A click must feel instant even on a slow server, so the page updates first and asks second: optimistic UI. When the server says no, the page puts things back and says so. ★★☆

“I saved four stalls on my laptop. My phone says I saved none.”

You'll demo (next class): with chaos on, click ♥ five times quickly on different stalls: each turns on at once. One of them fails: it turns back off and a message says which one. Reload: the server's list is what you see.

The core (start in class if you've connected, the minimum for the demo)

Four things, on top of your connected market. They count when they work with chaos on (control page).

GET /api/saved on start fills the ♥s; localStorage no longer stores them.
♥ on: PUT /api/saved/:id; off: DELETE. 204: no body to read.
The ♥ changes on click, before the response (optimistic).
A failed request rolls back that one ♥ and names the stall in a message.

The full feature (finish at home)

What has to work for the demo next class, not how. The core above is part of it.

Requests

On start, GET /api/saved fills state.saved (together with the stalls).
♥ on: PUT /api/saved/:id. ♥ off: DELETE /api/saved/:id. Both 204, no body.
localStorage no longer stores the saved ids.

States

The ♥ changes on click, before the response (optimistic).
A ♥ with a request in flight looks pending (dimmed), and can still be clicked: the last click decides.
"♥ 3 saved" counts what the page believes; after a reload, what the server knows.

Errors

A failed PUT or DELETE rolls that one stall back, and only that one.
A short message names the stall: "Couldn't save Mezcal Moon. Try again."
If GET /api/saved fails, the stalls still render; the ♥s are disabled with a note.

The endpoints you need

Method	Path	Answers
`GET`	`/api/saved`	200 · array of stall ids
`PUT`	`/api/saved/:id`	204 · 404 unknown stall · idempotent
`DELETE`	`/api/saved/:id`	204 · idempotent

Test in two browsers (or a normal and a private window): save in one, reload the other.

Edge cases (with chaos on, minutes 38–43)

Chaos on: ♥ five stalls quickly. Which ones survive a reload?
♥ on, then off, before the first response arrives.
DevTools → Network → Offline, click ♥.
Save in one browser, reload another.
Filter to Food while a save is pending.

Stretch, if you're done early

Undo: "Saved Mezcal Moon · Undo" for 5 seconds.
Retry the failed ones with one button.
Sync on focus: when the tab becomes visible, GET /api/saved again.

Stuck? One hint at a time

Network panel first: is the request sent, with what, and what came back? Then a hint.

Hint 1

To roll back, you need to know the value before the click. Where is it at the moment of the click?

Hint 2

On, off, on, quickly: three requests. Which response should decide what the ♥ shows?

Hint 3

PUT and DELETE are idempotent. What does that let you do when one fails?

Traps

Open when something behaves strangely

A failed save turns every ♥ off, not just the one that failed.
Fast on-off-on ends with the ♥ off, though the last click was on.
response.json() fails on a 204: "Unexpected end of JSON input".
The ♥ is right, the counter is wrong (or the other way round).

Before you start

This brief assumes Connect the market is done: api.js works, the stalls come from the API, loading and errors are handled. Then: A ♥ click sends PUT /api/saved/:id (204), and GET /api/saved in the Network panel lists that id after a reload.

Demo · next class, 3 minutes

Your 3 minutes

The happy path, with the Network panel open next to the page.
Chaos on: the loading state, one failure, and how the page recovers.
One request in code: the call, the status codes you handle, where the state changes.
One bug you hit, and the panel or the message that showed it to you.