The `cookieStore` API is offered as a modern replacement for `document.cookie`. What does it change about reading, writing and observing cookies, and what stays exactly the same?

## The three problems it addresses `document.cookie` has three structural defects that no amount of helper code fixes: it is a **string** you must parse, it is **synchronous** on the main thread, and it exists only on `document`, so a service worker cannot use it. The `cookieStore` interface, exposed as `window.cookieStore` in a document and `self.cookieStore` in a service worker, addresses all three. ## Structured reads ```js const c = await cookieStore.get('theme'); // { name: 'theme', value: 'dark', domain: 'example.com', // path: '/', expires: 1793827200000, secure: true, sameSite: 'lax' } const all = await cookieStore.getAll(); ``` The returned object carries the **attributes**, which is the single biggest functional gain: `document.cookie` can never tell you a cookie's path or expiry, so the delete-with-the-wrong-path bug is unavoidable there and avoidable here. `get()` resolves to `null` when there is no match rather than making you scan a string, and no `decodeURIComponent` dance is required for the pair itself. ## Writes that report failure ```js try { await cookieStore.set({ name: 'theme', value: 'dark', path: '/', expires: Date.now() + 86_400_000, // ms since epoch, not an HTTP date sameSite: 'lax', }); } catch (err) { // rejects when the browser refuses the write } await cookieStore.delete('theme'); // or delete({ name, path, domain }) ``` `set()` takes an options object — or the shorthand `set(name, value)` — and returns a promise. A refused write **rejects** instead of vanishing, which is the reliability difference that matters most in real code. `expires` is a timestamp in milliseconds, so no HTTP-date formatting. `delete()` still expires the cookie by name plus scope, and you still supply `path`/`domain` when the cookie was not written at the defaults. ## Observation instead of polling ```js cookieStore.addEventListener('change', (event) => { for (const c of event.changed) console.log('written', c.name, c.value); for (const c of event.deleted) console.log('removed', c.name); }); ``` With `document.cookie` there is no notification of any kind, so code that needs to react to a cookie written by another tab, by a `Set-Cookie` response, or by devtools has to poll on a timer. The `change` event ends that. In a service worker the equivalent is a `cookiechange` event on the global scope, which is how a worker can react to a session cookie disappearing. ## What is deliberately unchanged This is the half candidates forget, and the half interviewers are checking: - **`HttpOnly` still wins.** `cookieStore.get()` and `getAll()` exclude those cookies exactly as `document.cookie` does. The API is a better interface to the same store, not a privilege escalation. - **Scoping is unchanged.** A cookie is still identified by name plus domain plus path; the same delete-the-wrong-one hazard exists, only now you can *see* the path and get it right. - **The wire behaviour is unchanged.** Cookies still ride along on matching requests with the same size budgets and per-domain caps. - **Secure context only.** The API is not exposed on plain `http:` pages, so a fallback path is mandatory anyway for any non-HTTPS environment. ## Adopting it safely Support is genuinely uneven — it shipped in Chromium browsers (Chrome and Edge 87) and is not available everywhere, so the honest production pattern is a thin façade with feature detection: ```js const cookies = 'cookieStore' in globalThis ? { get: (n) => cookieStore.get(n).then((c) => c?.value) } : { get: async (n) => readFromDocumentCookie(n) }; ``` One more practical asymmetry: because `cookieStore` is asynchronous, a cookie you must have available before the first paint — a theme flag driving a class on `<html>`, for instance — is still better read synchronously from `document.cookie` in a blocking inline script. Async is the right default, but "needed before the first frame" is a real exception. ## The one-line summary `cookieStore` fixes the *interface* — structured, async, observable, worker-available, failure-reporting — while leaving the *policy* untouched: the same cookies, the same scoping rules, and the same HttpOnly blind spot.