Bug: Years view shows stale enabled/disabled years after isValidDate rules change
Package: react-datetime v3.3.1
Description
In v3.3.1, YearsView caches per-year disabled state in disabledYearsCache the first time it evaluates isValidDate (isDisabledYear in src/views/YearsView.js). That cache is never cleared for the lifetime of the YearsView instance.
When validation rules change at runtime (e.g. min/max date range, weekend rules, or other logic inside isValidDate), the years view can continue to show outdated enabled/disabled years because cached results are returned without re-calling isValidDate.
Note: DateTime.componentDidUpdate does not watch isValidDate, so changing the prop alone does not invalidate this cache.
MonthsView recalculates on each render; this issue appears specific to the years view cache.
Steps to reproduce
- Render
<Datetime isValidDate={validatorA} /> and open the years view.
- Observe which years are disabled.
- Update validation rules (e.g. change allowed date range) and pass
isValidDate={validatorB} (or the same stable callback whose logic now uses new data).
- Open the years view again — disabled years may still reflect the old rules.
Expected behavior
The years view should reflect the current isValidDate rules after they change.
Actual behavior
Cached year disabled state persists until YearsView is unmounted (e.g. full component remount via React key).
Proposed solutions
Option 1 — Imperative API (similar to navigate() / setViewDate())
Expose a ref method (e.g. clearDisabledYearsCache()) that clears disabledYearsCache, so consumers can invalidate explicitly when their validation rules change without remounting the entire picker.
Option 2 — Automatic invalidation when isValidDate changes
Clear or refresh the cache in YearsView when isValidDate changes (e.g. in componentDidUpdate).
Note: If consumers use a stable function reference with changing closure data, reference equality alone may not be enough; we could document that a new function reference or an explicit clear/remount is required, or consider an optional validationKey prop for semantic invalidation.
I'm happy to implement either approach and open a PR. Happy to follow whichever direction the maintainers prefer.
Bug: Years view shows stale enabled/disabled years after
isValidDaterules changePackage: react-datetime v3.3.1
Description
In v3.3.1,
YearsViewcaches per-year disabled state indisabledYearsCachethe first time it evaluatesisValidDate(isDisabledYearinsrc/views/YearsView.js). That cache is never cleared for the lifetime of theYearsViewinstance.When validation rules change at runtime (e.g. min/max date range, weekend rules, or other logic inside
isValidDate), the years view can continue to show outdated enabled/disabled years because cached results are returned without re-callingisValidDate.Note:
DateTime.componentDidUpdatedoes not watchisValidDate, so changing the prop alone does not invalidate this cache.MonthsViewrecalculates on each render; this issue appears specific to the years view cache.Steps to reproduce
<Datetime isValidDate={validatorA} />and open the years view.isValidDate={validatorB}(or the same stable callback whose logic now uses new data).Expected behavior
The years view should reflect the current
isValidDaterules after they change.Actual behavior
Cached year disabled state persists until
YearsViewis unmounted (e.g. full component remount via Reactkey).Proposed solutions
Option 1 — Imperative API (similar to
navigate()/setViewDate())Expose a ref method (e.g.
clearDisabledYearsCache()) that clearsdisabledYearsCache, so consumers can invalidate explicitly when their validation rules change without remounting the entire picker.Option 2 — Automatic invalidation when
isValidDatechangesClear or refresh the cache in
YearsViewwhenisValidDatechanges (e.g. incomponentDidUpdate).Note: If consumers use a stable function reference with changing closure data, reference equality alone may not be enough; we could document that a new function reference or an explicit clear/remount is required, or consider an optional
validationKeyprop for semantic invalidation.I'm happy to implement either approach and open a PR. Happy to follow whichever direction the maintainers prefer.