Skip to main content
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

All storage keys should:
  • 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

  1. UI State: {component}_{state}
    • sidebar_collapsed
    • modal_shown
    • tab_selected
  2. User Preferences: {feature}_preferences or user_{setting}
    • notification_preferences
    • user_language
    • user_timezone
  3. Selection State: selected_{entity}_id
    • selected_team_id
    • selected_project_id
    • selected_workspace_id
  4. Cache/History: {feature}_history or recent_{items}
    • search_history
    • recent_searches
    • visited_pages
  5. Feature Data: {feature}_{data_type}
    • dashboard_layout
    • form_draft
    • wizard_state
  6. 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 uses localStorage, 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
The enhanced event bus storage system provides a powerful, type-safe way to manage persistent state in the DeployStack frontend, making it easy to maintain user preferences and application state across sessions.