Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CalendarDay: Method toCalendarDay validates against Date instead of CalendarDay (IgxDatePicker disabledDates not working) #14938

Open
luiscla27 opened this issue Oct 22, 2024 · 0 comments
Assignees
Labels
🐛 bug Any issue that describes a bug 📆 calendar 🆕 status: new

Comments

@luiscla27
Copy link

luiscla27 commented Oct 22, 2024

Description

Attribute disabledDates of igx-date-picker doesn't work.

  • igniteui-angular version: 18.1.1
  • browser: Chrome 129.0.6668.103

Steps to reproduce

You may see the issue in this stackblitz example, steps:

  1. Open the stackblitz example
  2. You may see 2 date pickers, both have the same disabledDates configuration, however only 1 works.

The stackblitz example I made, only illustrates the bug, not the use case. In my particular case, I ran into that issue because I have an application that shares information between IFRAMES.

Result

The date value received at toCalendarDate is NOT an instance of Date, so the date value is never wrapped.

Expected result

Maybe use myDateVar.constructor.name.

Instead of validating dates against Date, validate it against CalendarDay (If already is an instance of CalendarDay, then do nothing, or else... do the wrapping).

Cause

I've debugged this a lot, and the root cause is this line at your CalendarDay date wrapper:

export function toCalendarDay(date: DayParameter) {
    return date instanceof Date ? CalendarDay.from(date) : date;
}

The issue is well documented when trying to use instanceof on multiple realms

JavaScript execution environments (windows, frames, etc.) are each in their own realm. This means that they have different built-ins (different global object, different constructors, etc.). This may result in unexpected results

I know this issue is particularly not commonly going to happen. However, I decided to post it... because, I consider a coding paradigm mistake to make validations against "what things not are", instead of "what they should be". There's plenty articles in the web as recommendations for the later statement, here's one from owasp, the general concept is to "use positive data validation".

Attachments

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug Any issue that describes a bug 📆 calendar 🆕 status: new
Projects
None yet
Development

No branches or pull requests

3 participants