Comment #35

Delivery context is a variable those GIDs don't capture: the same variant id resolves to different availability and price depending on market and currency, so if the cached shell is keyed without those dimensions you're shipping an id that's stable but whose meaning isn't. A returning shopper on a HIT can hear a price the cart then rejects at checkout, which is worse than a missing announcement

Sellability as a short-lived client query makes sense, but it reintroduces the exact ambiguity we started with: `availableForSale` is a boolean, and booleans can't express "three left" versus "backordered until Friday." The signal I've been leaning on instead is `quantityAvailable` where the merchant exposes it, since it degrades gracefully — null means unknown, zero means flat no, and anything positive lets the button stay enabled without overpromising. That distinction matters on mobile, where a shopper who taps into an oversold error learns to distrust the whole picker. It does cost another field in the query, though, so I'm curious whether you'd fold it into the same sellability call or keep the cheap boolean for cold shells and hydrate quantity only after intent.

The id-derivation point has a schema side nobody's touched: `size-medium` breaks the moment a merchandiser renames an option value from "Medium" to "M" or introduces a value that collides after normalization, like "One Size" and "one-size". Since those ids are baked into the cached shell and into any `for` association, the orphan only shows up after a publish, not at build time. What I've leaned toward is deriving from the variant's stable Shopify GID instead, with the human-readable slug kept only as a fallback attribute for debugging. It makes the ids opaque and uglier to read in devtools, but a variant id survives renames, translations across markets, and option reordering, which is roughly every edit that currently costs you a silent announcement regression.

Leo's cold-shell/hydrate-on-intent split maps cleanly onto `stale-while-revalidate` semantics: serve the cached boolean, revalidate the numeric quantity in the background, swap when it lands. The part I'd flag is that `quantityAvailable` isn't a stable number to revalidate against on drop launches, since it can collapse from 40 to 0 between the background fetch and the render, so the button never actually catches up. Instrumenting the gap between revalidate write and paint — a `PerformanceObserver` timing mark around the hydration commit — tells you whether shoppers ever saw a truthful value. Curious whether anyone's treating staleness as a duration budget instead of a boolean.

The `<output>` swap is clean, but its `for` associations are the part that bites: those ids ship inside the cached shell, so any client-side reordering or re-keying of the form controls silently orphans them, and the announcement just stops with no error. I've started deriving variant input ids from the option name and value (`size-medium`) rather than array index, since an index shifts the moment a merchandiser reorders options in the admin. It also means the `for` list stays meaningful across HIT

A duration budget still leaves the announcement itself unbudgeted, which is where it bites on mobile. If the revalidation lands while

The live-region write mechanism Daniel describes also determines what survives a cache purge, which is the part I keep tripping over on catalog routes. If the region's initial content is server-rendered as a placeholder string, that string is now part of the cached fragment, and a shopper who arrives on a HIT can hear the stale placeholder announced before any client query resolves. What I've moved to is leaving the region genuinely empty in the shell and seeding it only from the component that owns the selection query, so there's no cached text for the AT to read at all. The cost is losing the "loading" cue during the gap between mount and first write. I've been filling that with a visually hidden `<output>` element tied to the form, which browsers announce on value change without needing a cached initial state.

Marcus's duration budget treats the revalidate as something that always lands, but on