14 Client-side storage
Client-side storage in web browsers allows you to store data locally on a user’s device. Here are the main types:
14.2 2. Local Storage
Part of Web Storage API. Stores data with no expiration time.
// Store data
.setItem('user', JSON.stringify({name: 'John', age: 30}));
localStorage
// Retrieve data
const user = JSON.parse(localStorage.getItem('user'));
// Remove item
.removeItem('user');
localStorage
// Clear all
.clear(); localStorage
Characteristics: - Size limit: ~5-10MB (varies by browser) - Persists until explicitly deleted - Synchronous API (can block main thread) - Same-origin only - Stores strings only (need JSON.stringify for objects)
14.3 3. Session Storage
Similar to Local Storage but data expires when the tab closes.
// Same API as localStorage
.setItem('tempData', 'This disappears when tab closes');
sessionStorageconst temp = sessionStorage.getItem('tempData');
Characteristics: - Size limit: ~5-10MB - Data isolated per tab/window - Cleared when tab closes - Perfect for temporary form data
14.4 4. IndexedDB
A low-level API for storing large amounts of structured data.
// Open database
const request = indexedDB.open('MyDatabase', 1);
.onsuccess = (event) => {
requestconst db = event.target.result;
// Create transaction
const transaction = db.transaction(['users'], 'readwrite');
const store = transaction.objectStore('users');
// Add data
.add({id: 1, name: 'John', age: 30});
store; }
Characteristics: - Size limit: Browser-dependent (can be GBs) - Asynchronous API - Supports transactions - Can store complex data types (not just strings) - Good for offline applications
14.5 5. Cache API
Designed for storing HTTP responses for offline use (part of Service Workers).
// Store a response
.open('v1').then(cache => {
caches.add('/api/data.json');
cache;
})
// Retrieve from cache
.match('/api/data.json').then(response => {
cachesif (response) {
// Use cached response
}; })
Characteristics: - Stores Request/Response pairs - Primarily for Service Worker use - Good for offline-first strategies - Programmatic control over cache
14.6 Comparison Diagram
┌─────────────┬──────────┬───────────┬──────────┬────────────┐
│ Storage │ Size │ Lifetime │ Scope │ Data Type │
├─────────────┼──────────┼───────────┼──────────┼────────────┤
│ Cookies │ ~4KB │ Settable │ Domain │ String │
│ Local │ 5-10MB │ Permanent │ Origin │ String │
│ Session │ 5-10MB │ Tab/Window│ Origin │ String │
│ IndexedDB │ GBs │ Permanent │ Origin │ Any │
│ Cache API │ Varies │ Manual │ Origin │ HTTP Resp │
└─────────────┴──────────┴───────────┴──────────┴────────────┘
14.7 Best Practices
Choose the right storage:
- User preferences → Local Storage
- Shopping cart (temporary) → Session Storage
- Authentication tokens → Cookies (HttpOnly)
- Large datasets → IndexedDB
- Offline resources → Cache API
Handle errors:
try { .setItem('key', 'value'); localStoragecatch (e) { } // Handle quota exceeded or private browsing console.error('Storage failed:', e); }
Check availability:
if (typeof(Storage) !== "undefined") { // localStorage/sessionStorage supported }
Consider privacy:
- Users can clear storage
- Private/incognito modes may limit storage
- Always have fallbacks
Each storage type serves different use cases. For your radiology AI applications, you might use IndexedDB for storing DICOM metadata locally, Local Storage for user preferences, and Session Storage for temporary image annotations during a viewing session.