Lesson 0003 · ~12 minutes

Deal-breakers & integration risks

One skill: run a 60-second design-review scan — when sessionStorage is the wrong tool, and which edges kill “just stash it in the session.”

← Lesson 2 Lesson 4 → Checklist API sheet Glossary Mission

Win for this lesson

You can reject bad proposals quickly (multi-tab bus, tokens, bulk data, “always available”) and green-light a tab-scoped wizard draft with eyes open on sync cost and write failures.

Repair pass (from lesson 2)

Two sticky spots from last time — lock them before the scan:

C — events: A sessionStorage.setItem in Tab A does not fire storage on Tab B (or on Tab A). Session maps are not shared across tabs (MDN).
E — availability: Don’t trust typeof sessionStorage alone. Probe with setItem + removeItem (MDN storageAvailable) and still try/catch production writes.

1. Wrong tool (reject before API details)

Requirement	Usually not sessionStorage	Prefer
Multi-tab live sync of one key	Tab-private map + no cross-tab events	`localStorage` events, `BroadcastChannel`, or server
Survive browser restart / all tabs	Dies when the tab closes	`localStorage` (tiny) or server prefs
Large structured / offline entities	Strings, ~few MB, sync, no workers	IndexedDB
App shell / HTTP assets offline	Not Request/Response storage	Cache API (+ SW)
Access / refresh tokens	Any script can read (XSS loot)	HttpOnly cookies / hardened session design
Worker-owned pipeline state	`Storage` is `Window`-only	IndexedDB (or message the window)

Lesson 1 still holds: sessionStorage wins for small tab-scoped session state — isolation is the feature, not a bug (web.dev, HTML ticket-window motivation).

2. Multi-tab myths (the event deal-breaker)

Design reviews often say: “we’ll put the flag in sessionStorage and listen for storage in other tabs.” That pattern is for localStorage, not sessionStorage (MDN Using guide).

sessionStorage: no shared map across tabs → no cross-tab storage events.
Writing document: never receives its own storage event for either store.
Opener copy: window.open starts with a copy of sessionStorage, then diverges — still not a live channel (MDN).

Steal this reject line

“sessionStorage is for isolation, not broadcast. If two tabs must stay in sync, don’t use it as the bus.”

3. Sync cost, quota, and “always works”

Web Storage is synchronous on the main thread (MDN, web.dev). Fine for occasional small reads/writes; bad for every keystroke on a huge string or polling loops.

Practical size is on the order of ~5 MB and strings only — not a general database.
setItem can throw QuotaExceededError or fail when the user/browser disables storage (often tied to cookie blocking).
Probe with MDN’s storageAvailable("sessionStorage"), and still catch write errors in product paths.

4. Security: sticky notes are not vaults

Anything in Web Storage is readable by same-origin script. XSS that can run on your origin can dump every key. Putting long-lived API tokens in sessionStorage or localStorage is a classic foot-gun — “tab only” does not make it httpOnly.

Prefer patterns where secrets never land in script-readable storage (e.g. httpOnly cookies for session cookies, short-lived memory tokens with a careful design). Full auth architecture is out of scope here; the deal-breaker is: don’t stash secrets in Web Storage by default.

5. Practice — reject or green-light

Equal-length options. Includes a deliberate re-test of the lesson-2 soft spots.

Scenario A

Proposal: “Put cart count in sessionStorage; other open tabs listen for storage and update the badge.”

Scenario B

Checkout wizard step index: small string, must survive reload in this tab only; parallel checkout tabs must stay independent.

Scenario C

Auth proposal: store the long-lived OAuth access token in sessionStorage so SPA fetches can attach Authorization after reload.

Scenario D · re-test C

Tab A: sessionStorage.setItem("k","1"). Same-origin Tab B open, no iframes. Who receives storage?

Scenario E · re-test E

Before shipping a sessionStorage-backed draft, what is the sound availability posture?

6. What to remember

Reject: multi-tab bus, durable prefs, bulk data, tokens, worker-owned state.
Isolation ≠ broadcast — no cross-tab storage for session writes.
Sync + small quota → occasional small strings only; probe + catch.
Green-light: tab-private wizard/UI session flags with eyes open.

Ask your teacher A real proposal on your team (cart badge, auth, multi-tab editor)? Paste it and we’ll run the checklist. Follow-ups are part of the method.

Primary source (read next)

web.dev — Storage for the web (why Web Storage is the “use with caution” bucket). For the event and probe details, keep MDN Using the Web Storage API and the checklist open.