Skip to content

feat: persist navigation state#354

Open
TheBullRing wants to merge 1 commit intoFamousWolf:mainfrom
TheBullRing:feature/persist-navigation
Open

feat: persist navigation state#354
TheBullRing wants to merge 1 commit intoFamousWolf:mainfrom
TheBullRing:feature/persist-navigation

Conversation

@TheBullRing
Copy link
Copy Markdown
Contributor

Feature: Persist Navigation State
Problem
The week-planner-card previously lost its navigation state (current date view) whenever the component was re-rendered or the configuration changed (e.g., adding/toggling calendars). This caused the view to reset to "today", frustrating users who were navigating through future/past dates.

Solution
Implemented a persistence mechanism using a static class property WeekPlannerCard.persistence to store the navigation offset for each card instance.

Key Changes

  1. _card_id Configuration: Added a new optional configuration parameter card_id. If provided, the card uses this ID to key its state in the persistent storage.

  2. State Persistence: The _navigationOffset (which determines the viewed date range) is saved to WeekPlannerCard.persistence[card_id] whenever navigation occurs (next/prev/today).

  3. State Restoration: When setConfig is called (e.g., on dashboard refresh or config update), the card checks for an existing state for the given card_id and restores the _navigationOffset.

  4. Events: Dispatches a new week-planner-date-changed event whenever the navigation changes, containing the startDate, navigationOffset, and card_id.

Configuration Example

yaml
type: custom:week-planner-card
card_id: my_planner_main  # Unique ID required for persistence
calendars:
  - entity: calendar.family

Verification
verified that adding card_id preserves the view when toggling other config options.
verified that without card_id, behavior remains unchanged (no persistence).

@FamousWolf
Copy link
Copy Markdown
Owner

@TheBullRing I'm not sure what issue you're trying to fix with this. As far as I can see this only happens if you change the card configuration. How often do you change this?

@TheBullRing
Copy link
Copy Markdown
Contributor Author

My integration uses the my-skylight-calendar project (https://github.com/mohesles/my-skylight-calendar), which is based on the week-planner-card component.
The dashboard provides a consolidated view of multiple calendars, each controlled by an individual toggle button that shows or hides the corresponding calendar.
When a calendar is toggled, the week-planner-card is re-rendered.
This behavior works correctly under normal conditions but introduces a problem when navigation controls are used.

When a user navigates away from the current week (e.g., advancing to the next week using the navigation arrows), the navigation state is lost if a calendar toggle is pressed.

After the re-render, the view unexpectedly resets to the current week instead of maintaining the previously selected date.
This results in a degraded user experience, as users planning ahead must re-navigate to their desired week every time a toggle action occurs.

Resolution Introduced in PR
A persistence mechanism has been implemented to maintain the user’s navigation state across re-renders.
Key enhancements include:

  1. card_id Configuration
    Users can now assign a unique card_id within the configuration of each week-planner-card:
type: custom:week-planner-card
card_id: my_kitchen_planner
# ... other config
  1. Central Persistence Store
    A static persistence object is now used to store navigation offsets, keyed by card_id.
    This ensures each card retains its own navigation state independently.

  2. Automatic Save and Restore of Navigation Offset

On load, the card checks for an existing saved offset associated with its card_id and restores it.
When the user selects "Next", "Previous", or "Reset", the updated offset is saved automatically.

  1. Event-Based State Signaling
    A week-planner-date-changed event is now dispatched whenever the navigation state changes.
    This enables additional dashboard components to react synchronously, if necessary.

With the persistence mechanism in place, navigation state is preserved across card re-renders, resolving the usability issue and ensuring users can reliably plan future dates without repeated navigation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants