Frontend Storage System
The storage system is built into the global event bus and provides persistent data management across route changes and browser sessions. This system uses localStorage with a type-safe API and automatically emits events when data changes.📖 For event bus fundamentals, see Global Event Bus
Overview
The storage system solves common frontend challenges such as:- Persistent State: Maintain application state across route changes and page refreshes
- Type Safety: Full TypeScript support with generic methods
- Easy Integration: Simple API that works with the existing event bus
- Automatic Cleanup: Consistent storage key management with prefixing
- Event Integration: Storage changes emit events for reactive updates
Architecture
Storage Configuration
The storage system is built into the event bus and uses a centralized configuration:Type Safety
All storage operations are type-safe using TypeScript generics:Usage
Basic Storage Operations
Storing Data
Retrieving Data
Checking and Clearing Data
Storage Key Naming Convention
The storage system follows strict naming conventions to ensure consistency and prevent conflicts across the application.Naming Pattern
- Use snake_case (lowercase with underscores)
- Start with the feature name or domain
- End with a descriptive identifier
- Be specific and meaningful
Examples
Storage Key Categories
-
UI State:
{component}_{state}
sidebar_collapsed
modal_shown
tab_selected
-
User Preferences:
{feature}_preferences
oruser_{setting}
notification_preferences
user_language
user_timezone
-
Selection State:
selected_{entity}_id
selected_team_id
selected_project_id
selected_workspace_id
-
Cache/History:
{feature}_history
orrecent_{items}
search_history
recent_searches
visited_pages
-
Feature Data:
{feature}_{data_type}
dashboard_layout
form_draft
wizard_state
-
User Onboarding:
{feature}_completed
or{feature}_cancelled
walkthrough_completed
tutorial_completed
onboarding_skipped
Adding New Storage Values
Step 1: Define Your Storage Key
Follow the naming convention and optionally add your key to the configuration for better organization:Step 2: Use in Components
Step 3: Listen for Storage Changes (Optional)
Real-World Examples
Example 1: Theme Persistence
Example 2: Dashboard Layout Persistence
Best Practices
1. Follow Naming Conventions
Always use the established naming pattern{feature}_{description}
with snake_case:
2. Provide Default Values
3. Use Type Safety
4. Handle Storage Errors Gracefully
5. Clean Up When Appropriate
Storage Events
The storage system emits events when data changes, allowing for reactive updates:Technical Details
Storage Implementation
- Prefix: All keys are prefixed with
deploystack_
to avoid conflicts - Serialization: Data is stored as JSON strings using safe parsing
- Error Handling: All storage operations include try-catch blocks
- Type Safety: Generic methods provide compile-time type checking
- Event Integration: Storage changes emit
storage-changed
events
Browser Compatibility
The storage system useslocalStorage
, which is supported in all modern browsers. The system gracefully handles storage errors (e.g., when localStorage is disabled or full).
Performance Considerations
- Synchronous Operations: localStorage operations are synchronous but fast
- JSON Serialization: Large objects may impact performance during serialization
- Storage Limits: localStorage typically has a 5-10MB limit per domain
- Event Frequency: Storage change events are emitted for every setState/clearState call
Related Documentation
- Global Event Bus - Core event system that powers storage