Concepts in TypeScript & Web APIs, page 4
localStorage: Your Browser's Persistent Key-Value Store
localStorage is a simple dictionary saved in the browser that persists after the tab closes. Use it to save user settings like a theme. The footgun: all values are strings, so numbers and booleans need manual conversion, like parsing 'true' back to a boolean.
sessionStorage: Tab-Specific Browser Memory
sessionStorage is temporary browser memory isolated to a single tab. Use it to save state within a single user workflow, like form data. The footgun: unlike localStorage, this data is *not* shared between tabs, even for the same site.
Storing Objects in Web Storage: The JSON Step
Web Storage only stores strings. To save complex data like objects, you must first serialize them with JSON.stringify(). This is essential for persisting user settings or session info.
HTTP Cookies: State for a Stateless Web
Think of a cookie as a server's nametag for your browser. Since HTTP is stateless, this nametag helps the server remember you across requests for logins, shopping carts, or personalization. The main footgun is security: always use security flags.
IndexedDB: A NoSQL Database in Your Browser
Think of IndexedDB as a NoSQL database in the browser, built for large structured data that localStorage can't handle. It's ideal for offline apps or caching large assets. The footgun: browsers can evict your data, so it's not permanent storage.
IndexedDB Object Stores: Your Browser's NoSQL Table
An IndexedDB Object Store is like a NoSQL table in your browser, holding JavaScript objects by key. Use it for offline data like to-do lists or cached API responses. The main footgun: you can only create stores during a database version upgrade.
IndexedDB Transactions: The Gatekeepers of Data
An IndexedDB transaction is a short-lived container for all database operations, ensuring data integrity. Use it for any read or write. The main footgun: transactions auto-commit if idle, so you must queue all requests synchronously without waiting.
Choosing the Right Client-Side Storage
Client-side storage turns the browser into a mini-database for faster loads and offline access. It's used for remembering user preferences or caching assets.
IndexedDB Indexes: Fast Queries in the Browser
An IndexedDB index is like a book's index, letting you quickly find records by a specific property without scanning the entire dataset. It's essential for fast queries on non-primary keys, like looking up a user by email.
IndexedDB Cursors: Iterate Large Datasets Efficiently
An IndexedDB cursor is a pointer for walking through records one by one, avoiding loading a whole dataset into memory. Use it to efficiently process large browser databases.
IndexedDB Versioning: The 'upgradeneeded' Gatekeeper
IndexedDB uses a version number to manage schema changes. Incrementing the version in indexedDB.open() triggers a special upgradeneeded event, which is the only context where you can create or modify object stores and indexes.
Cache API: Manual Control Over Network Responses
The Cache API is a key-value store for network requests you control directly, unlike the browser's automatic HTTP cache. Use it in service workers for offline support or to pre-cache app assets.
Manipulate Browser History with pushState and replaceState
Make a single-page app feel like a multi-page site. pushState changes the URL without a full page reload, creating a new browser history entry. This is essential for SPAs to enable shareable links and a working back button.
The `popstate` Event: Handling Browser History Navigation
The popstate event lets your app react to browser back/forward clicks. It's key for SPAs to update views without a full reload. The main footgun: the event fires before the document is fully updated, so your handler might read a stale DOM.
Web Workers: Keep Your UI Responsive During Heavy Tasks
A Web Worker is like a background helper, running heavy JavaScript tasks in a separate thread so your UI never freezes. Use it for complex calculations or data fetching. The main footgun: workers cannot directly manipulate the DOM.
Service Worker Registration: Claiming Your Control Scope
Registering a service worker is like assigning a security guard (your script) to a specific area (the scope) of your site for offline support. The footgun: by default, a worker can only control its own directory, not the whole site.
Worker postMessage: The Structured Clone Pipe
Worker postMessage moves data between threads via structured cloning. Use it to offload heavy work without blocking the UI. The message argument is mandatory, so omitting it is an error and you must pass null when there is no data.
The Service Worker Lifecycle: Register, Install, Activate
A service worker is a background proxy that lets your app work offline. Its lifecycle—register, install, activate—governs how it takes control of pages. The biggest footgun: a new worker waits for old clients to close before activating, delaying updates.
Intercept Network Requests with the `fetch` Event
The fetch event turns your Service Worker into a programmable network proxy. Use it to intercept outgoing requests to serve assets from a cache for offline support or to synthesize custom responses.
Shared Workers: One Background Script for Multiple Tabs
A SharedWorker is a single background script shared across multiple tabs or windows from the same origin. Use it to manage a single WebSocket connection or sync state between pages. The footgun: each tab must call port.start() on its own message port.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles