Feature: Add Local Data Persistence for Dashboards

[NithinRegidi]

Description

Currently, dashboard data loaded from APIs is not persisted locally. When users refresh the page, all data and custom configurations are lost. This creates a poor user experience and prevents users from saving their work or maintaining custom dashboard setups across sessions.

Problem Statement

• Data Loss on Refresh: All loaded data, chart configurations, and slicer states are lost when the page is refreshed
• No Save/Load Functionality: Users cannot save custom dashboard configurations for later use
• Session Management: Each session requires reconfiguring data sources and parameters from scratch
• Productivity Impact: Users working with complex dashboards cannot maintain their work state

Proposed Solution

Implement browser-native local storage (localStorage) to save and restore dashboard state, with manual and automatic restore options.

Feature Specifications

Core Functionality

1. Save Dashboard: Store current data objects, chart configurations, and slicer states to localStorage
2. Load Dashboard: Restore previously saved state from localStorage
3. Clear Data: Provide option to remove stored data for privacy
4. Auto-Restore: On page load, check for saved state and prompt user to restore

User Interface Changes

• Add three buttons to the dashboard area:
  • "Save Dashboard" - saves current state
  • "Load Dashboard" - restores from saved state
  • "Clear Data" - removes all saved state with confirmation dialog

Data to Persist

• Data objects fetched from APIs
• Chart configurations and display settings
• Slicer/filter selections (row counts)
• Data source selection and input parameters

Benefits

• Improved UX: Users can resume work without reconfiguring
• Productivity: Faster workflow for repeated dashboard uses
• Offline Access: Basic functionality available without API calls
• Privacy Control: Users can clear data as needed
• No Dependencies: Uses browser-native APIs only

[github-actions]

👋 Thank you for raising an issue! We appreciate your effort in helping us improve. A maintainer from OpenDots will review it shortly. Stay tuned!

[NithinRegidi]

✅ Required Labels (Both Mandatory)

Before a PR is merged, it must contain exactly two labels:

1. apertre3.0 – Identifies the PR as part of the Apertre 3.0 program
2. One Difficulty Label – easy / medium / hard

⚠️ PRs without both labels will NOT be considered valid, even if the code is correct.

@multiverseweb Please assign this issue to me.

[multiverseweb]

Go ahead, @NithinRegidi.

[NithinRegidi]

@Solix45456767
Thank you so much for the comprehensive actionable advice and for stepping up to implement this feature! 🙏