-
-
Notifications
You must be signed in to change notification settings - Fork 14
Description
Firstly, thank you for creating this library specifically for the date-time picker implementation; it is surprising that Angular material hasn't addressed this after 4 years of requests! Your implementation feels right at home alongside other material components and works beautifully :)
One aspect which I feel makes use of the library difficult however is the lack of emitted Date values whenever the user is navigating through views. Specifically take the following typical flow:
- Open date-time picker (component initialises with
new Date()-> Mon May 09 2022 12:34:56) - Select a date (e.g. 10th May 2022 -> Tue May 10 2022 00:00:00)
- Select an hour (e.g. 17:00 -> Tue May 10 2022 17:00:00)
- Select a minute (e.g. 30 -> Tue May 10 2022 17:30:00)
- Apply (using a button with the
matDatepickerApplydirective)
I would expect to be able to access a Date object which contains the currently highlighted date emitted each time the user makes a selection (steps 2, 3 and 4) and ideally is initialised with the value that the datepicker displays when opened (step 1). To my knowledge there is no way to access this value using the APIs provided. This means in practice that I have no way of knowing what the user has selected until step 5 at which point Tue May 10 2022 17:30:00 is correctly emitted via (dateChange).
There are concrete drawbacks to not having this information being made available, mainly in providing a unified user experience within the component and in other related components. For example:
- Triggering validation logic, e.g. disabling the Apply button if the currently preselected value exceeds
min/maxvalidation (related downstream issue: https://github.com/matheo/angular/issues/47) - Triggering logic which is dependent on the user's currently highlighted selection, e.g. displaying a preview date under the form field or in a sidebar
- Triggering logic which is dependent on the value that the date picker initialises with, e.g. a warning explaining why the current value is invalid and a new value may be required to be selected
The ideal implementation would expose the following APIs at minimum (arbitrary names) in much the same way that the dateChange interface works:
@Output() dateSelect: EventEmitter<Date | null>dateSelected: Date | null
Note: The first image demonstrates the scenario in which it would be beneficial to disable the 'Select' button as the currently highlighted date is clearly out of valid range. The button would be reenabled on highlighting a valid date, as in the second image


Please let me know your thoughts and thanks again for the library!