LocalStorage Data Management

Purpose

This subtopic addresses the need to persistently store, retrieve, and manage historical meeting data within the browser environment. While the parent topic, Persistent Meeting History, covers the broader functionality of storing and retrieving past meeting records, LocalStorage Data Management specifically abstracts and encapsulates all interactions with the browser's localStorage API. This abstraction ensures meeting data can be saved reliably, retrieved efficiently, and maintained within set constraints, such as limiting the number of stored records to prevent unbounded growth.

By centralizing localStorage operations behind a dedicated interface, the system gains improved maintainability, testability, and clarity in data persistence concerns, decoupling storage logic from meeting state management and UI rendering.

Functionality

The core responsibilities of this subtopic include:

• Saving Meeting Data: Appending new meeting records to the existing collection stored in localStorage, while enforcing a maximum retention limit (10 records). This prevents excessive storage use and keeps historical data manageable.

• Loading Meeting Data: Retrieving the stored meeting array from localStorage and parsing it back into usable JavaScript objects for display or further processing.

• Removing Specific Data: Deleting stored items by key, facilitating targeted cleanup or updates.

• Clearing All Stored Data: Providing a method to erase all stored meeting history, supporting the "Clear Storage" feature in the UI.

• Graceful Degradation: Detecting whether localStorage is supported in the user's browser and safely no-op if unavailable, preventing runtime errors.

The implementation is encapsulated in the Warehouse class, which acts as a façade over localStorage operations:

export default class Warehouse {
    local = false;
    defaultKey = 'meetings';

    constructor() {
        if (typeof (Storage) !== "undefined") {
            this.local = true;
        }
    }

    save(payload, key=this.defaultKey) {
        if (!this.local) return null;
        let pastMeetings = JSON.parse(this.load()) || [];
        pastMeetings.push(payload);
        if (pastMeetings.length > 10) pastMeetings.shift();
        return window.localStorage.setItem(key, JSON.stringify(pastMeetings));
    }

    load(key=this.defaultKey) {
        if (!this.local) return null;
        return window.localStorage.getItem(key);
    }

    remove(key=this.defaultKey) {
        if (!this.local) return null;
        return window.localStorage.removeItem(key);
    }

    clear() {
        if (!this.local) return null;
        return window.localStorage.clear();
    }
}

Key Workflows

• Saving a Meeting:

  1. Load existing meetings array from localStorage.

  2. Append the new meeting record.

  3. Enforce a cap of 10 records by removing the oldest if exceeded.

  4. Serialize and save the updated array back to localStorage.

• Loading Meetings:

  • Fetch the JSON string from localStorage and parse it into an array.

  • Return null or an empty array if no data exists or localStorage is unsupported.

• Clearing Storage:

  • Remove all keys or clear the entire localStorage space related to meetings.

• Removing Specific Entries:

  • Delete data by key when needed (though primarily the default key is used).

This subtopic ensures reliability and limits on stored data, which prevents stale or excessive meeting records cluttering the browser storage.

Integration

LocalStorage Data Management integrates tightly with its parent topic, Persistent Meeting History, by serving as the underlying persistence layer. When a meeting completes in the Real-Time Meeting Cost Tracking module, the finalized meeting data is passed to the Warehouse instance for storage.

The stored data is later retrieved by the Historical Meeting Display subtopic, which formats and presents the saved records to the user in a readable table. The clear storage functionality, exposed via UI controls managed in User Interaction and Interface, invokes methods from this subtopic to erase historical data.

This separation allows the UI and display logic to focus on presentation without concern for storage mechanics, and the meeting lifecycle logic to remain clean and focused on cost/time tracking.

flowchart TD
UI[User Interface] -->|Save meeting data| Warehouse["Warehouse (LocalStorage Data Management)"]
Warehouse -->|Store meeting records| localStorage["(Browser localStorage)"]
Warehouse -->|Load meeting records| PastMeetings[Historical Meeting Display]
UI -->|Clear storage command| Warehouse

The diagram illustrates how UI actions trigger storage operations via the Warehouse, which abstracts direct localStorage interaction, coordinating data flow to and from persistent storage and the display components.

This focused data management layer is critical to maintaining a smooth user experience, ensuring that meeting histories persist across sessions without overloading browser storage or complicating other modules.