Skip to content

FIX: Calendar view (month/year) is not reset to selected input date after close/reopen#725

Open
MikeP707 wants to merge 2 commits into
wojtekmaj:mainfrom
MikeP707:bug/calendar-reset-after-close-reopen
Open

FIX: Calendar view (month/year) is not reset to selected input date after close/reopen#725
MikeP707 wants to merge 2 commits into
wojtekmaj:mainfrom
MikeP707:bug/calendar-reset-after-close-reopen

Conversation

@MikeP707

Copy link
Copy Markdown

Calendar Reopen View Reset in DatePicker

Problem

When the date picker calendar is opened and the user browses to another month or year without selecting a date, closing and reopening the calendar can keep the last browsed view.

That behavior is confusing because the selected input value was never changed, so the calendar should reopen on the current selected date instead.

Current fix implementation

The fix in packages/react-date-picker/src/DatePicker.tsx now controls React-Calendar's view explicitly using the activeStartDate prop.

DatePicker keeps its own activeStartDate state and resets it when the calendar is opened. The Calendar component receives that date and updates it through onActiveStartDateChange while the user navigates.

What changed in DatePicker.tsx

  • activeStartDate state was added.
  • activeStartDate is initialized from the current value.
  • When the calendar is opened, activeStartDate is reset from the selected input date before isOpen becomes true.
  • Calendar is rendered with:
    • activeStartDate={activeStartDate ?? undefined}
    • onActiveStartDateChange={({ activeStartDate }) => setActiveStartDate(activeStartDate)}

Why this works

  • React-Calendar uses activeStartDate to determine which month/year to display.
  • By controlling that prop from DatePicker, the selected value and the open calendar view stay in sync.
  • When the calendar is reopened, DatePicker explicitly resets activeStartDate from the current selected value, so the calendar always starts on the selected date.
  • This avoids relying on React remounting behavior and preserves the Calendar component across open/close cycles.

Implementation details

The current code flow is:

  1. Compute activeStartDate from the selected value.
  2. Store it in state with useState.
  3. Reset activeStartDate when opening the calendar, so the first visible month/year matches the selected date.
  4. Keep activeStartDate synced while the calendar is open using onActiveStartDateChange.
  5. Also support external isOpen prop updates with a small effect that resynchronizes the view when isOpen becomes true from outside.

Example from current implementation

const [activeStartDate, setActiveStartDate] = useState<Date | null | undefined>(
  getActiveStartDateFromValue(value),
);

function openCalendar({ reason }: { reason: OpenReason }) {
  if (shouldOpenCalendar) {
    if (!shouldOpenCalendar({ reason })) {
      return;
    }
  }

  setActiveStartDate(getActiveStartDateFromValue(value));
  setIsOpen(true);

  if (onCalendarOpen) {
    onCalendarOpen();
  }
}

useEffect(() => {
  if (isOpen) {
    setActiveStartDate(getActiveStartDateFromValue(value));
  }
}, [isOpen]);

<Calendar
  activeStartDate={activeStartDate ?? undefined}
  locale={locale}
  maxDate={maxDate}
  maxDetail={maxDetail}
  minDate={minDate}
  onActiveStartDateChange={({ activeStartDate }) => setActiveStartDate(activeStartDate)}
  onChange={(value) => onChange(value)}
  value={value}
  {...calendarProps}
/>

Trade-offs

Pros

  • Explicit control over calendar view state.
  • Avoids remounting the Calendar component on every open.
  • Keeps the selected date and displayed month/year synchronized.
  • Easier to reason about than forcing a component reset with key.

Cons

  • Adds a small amount of additional state and update logic in DatePicker.
  • Requires ensuring the controlled activeStartDate stays in sync with value when the calendar is reopened.

Recommendation

This controlled activeStartDate approach is the preferred solution for this bugfix.

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.

1 participant