You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Datepicker: Ability to differentiate whether a selected event is triggered by clicking on a calendar cell or by clicking on a date in the calendar's datepicker
#8433
Closed
sami1riaz opened this issue
Feb 9, 2024
· 5 comments
· Fixed by #8543
Is your feature request related to a problem or use case? Please describe.
The Soho Calendar currently triggers the same event (SohoCalendarDateSelectedEvent) when a date in the datepicker is clicked on and when a calendar cell is clicked on. We would like to be able to differentiate between the two events.
It would also be nice to be able to differentiate between events that are triggered from clicking the Today button and clicking into a new month's date.
Describe the solution you'd like
Ideally, a property set for the event that can indicate where the action is being triggered from (datepicker, calendar cell, today button e.t.c) would help us to set different behaviours based on that property
Describe alternatives you've considered
N/A
Additional context
We are trying to open a modal when a cell in the calendar is clicked on. We do not want a modal to be opened when a date in the date picker is clicked on though. If there was a property on the SohoCalendarDateSelectedEvent that can tell us where the event is being triggered from, we can then use that to check if the modal should be opened or not.
The text was updated successfully, but these errors were encountered:
tmcconechy
changed the title
Ability to differentiate whether a selected event is triggered by clicking on a calendar cell or by clicking on a date in the calendar's datepicker
Datepicker: Ability to differentiate whether a selected event is triggered by clicking on a calendar cell or by clicking on a date in the calendar's datepicker
Feb 9, 2024
@tmcconechy , I noticed that this is also creating an accessibility issue. When a user uses the arrow keys to navigate the calendar cells, the selected event is triggered causing a modal to open up (if that is the behavior set for the selected event). Any suggestions regarding that?
Our design does not use double click to open the modal. We're using the selected event so its causing an issue for us. I can discuss that with our designers/BAs to see if we should use double click to open the modal. But would this be considered a limitation for the component? Not being able to differentiate between selecting a cell and navigating to a cell?
Kind of like how our date picker allows us to navigate using arrow keys and only if you click on a date (or press enter or space) then it selects that date.
In our example we also provided a button in addition to dblclick. I would do that and maybe even consider a shortcut key. Click wont work as its already the action for clicking the day. Unless you always want a dialog to show when you click it.
Is your feature request related to a problem or use case? Please describe.
The Soho Calendar currently triggers the same event (SohoCalendarDateSelectedEvent) when a date in the datepicker is clicked on and when a calendar cell is clicked on. We would like to be able to differentiate between the two events.
It would also be nice to be able to differentiate between events that are triggered from clicking the Today button and clicking into a new month's date.
Describe the solution you'd like
Ideally, a property set for the event that can indicate where the action is being triggered from (datepicker, calendar cell, today button e.t.c) would help us to set different behaviours based on that property
Describe alternatives you've considered
N/A
Additional context
We are trying to open a modal when a cell in the calendar is clicked on. We do not want a modal to be opened when a date in the date picker is clicked on though. If there was a property on the SohoCalendarDateSelectedEvent that can tell us where the event is being triggered from, we can then use that to check if the modal should be opened or not.
The text was updated successfully, but these errors were encountered: