Uh oh!
There was an error while loading. Please reload this page.
refactor(datepicker): move keyboard events handlers into the views - #9775
Conversation
mmalerba
left a comment
There was a problem hiding this comment.
This feels much better to me, having logic for each of the views mixed into the calendar definitely felt wrong
| this._getValidDateOrNull(this._dateAdapter.deserialize(value)) || this._dateAdapter.today(); | ||
| const oldActiveDate = this._activeDate; | ||
| const validDate = | ||
| this._getValidDateOrNull(this._dateAdapter.deserialize(value)) || this._dateAdapter.today(); |
There was a problem hiding this comment.
nit: indent continuation lines by 4
There was a problem hiding this comment.
Oh, I didn't know that was the rule. 😃
| } | ||
| /** Focuses the active cell after the microtask queue is empty. */ | ||
| _focusActiveCell() { |
There was a problem hiding this comment.
could we move this logic to the calendar table instead of repeating it?
| this._userSelected(); | ||
| } | ||
| _userSelected(): void { |
There was a problem hiding this comment.
nit: I don't think this needs to be its own function, this._userSelected() is only a couple characters shorter than this._userSelection.emit()
| @Output() readonly selectedValueChange: EventEmitter<number> = new EventEmitter<number>(); | ||
| constructor(private _elementRef: ElementRef, | ||
| private _ngZone: NgZone) { |
There was a problem hiding this comment.
looks like this will fit on one line?
| this._init(); | ||
| } | ||
| if (this._dateAdapter.compareDate(oldActiveDate, this._activeDate)) { | ||
| this.activeDateChange.emit(this._activeDate); |
There was a problem hiding this comment.
are we sure we want to emit here? it seems strange to emit in response to the @Input() changing. I would have expected it to only emit if the active date changed due to user interaction (click, keyboard, etc)
There was a problem hiding this comment.
It's here for convenience (just because there was a single line above saving the previous activeDate 😸), but you're right. This is far from being the best place to put it. I'll move it.
Instead of just checking the length of the constructor arguments, we now check the types of the constructor or super call. This means that we can *way* better report invalid signatures for constructor changes like for the `MatCalendar` (angular#9775). Just relying on the length of arguments means that *order* is being ignored. This also makes maintaining the constructor signature changes easier (there are a lot of instances for V7).
Instead of just checking the length of the constructor arguments, we now check the types of the constructor or super call. This means that we can *way* better report invalid signatures for constructor changes like for the `MatCalendar` (angular#9775). Just relying on the length of arguments means that *order* is being ignored. This also makes maintaining the constructor signature changes easier (there are a lot of instances for V7).
Instead of just checking the length of the constructor arguments, we now check the types of the constructor or super call. This means that we can *way* better report invalid signatures for constructor changes like for the `MatCalendar` (angular#9775). Just relying on the length of arguments means that *order* is being ignored. This also makes maintaining the constructor signature changes easier (there are a lot of instances for V7).
…12970) Instead of just checking the length of the constructor arguments, we now check the types of the constructor or super call. This means that we can *way* better report invalid signatures for constructor changes like for the `MatCalendar` (#9775). Just relying on the length of arguments means that *order* is being ignored. This also makes maintaining the constructor signature changes easier (there are a lot of instances for V7).
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
This should be blocked until #9727 is merged.@mmalerba, as #9727 hasn't been merged yet, I can merge this into that one.There are a few things to discuss before though. Originally the keyboard events (basically
(keydown)) were listened to at this markup:https://github.com/angular/material2/blob/c7201984d4570e2bf17fbf4afce0dc4400f863f5/src/lib/datepicker/calendar.html#L23-L24
As now the events are being handled inside each view, I moved the listening part to each view markup, like the snippet below, from
month-view.htmlAlso, I thought it'd be better to move the
a11ytests fromcalendar.spec.tsto each view spec file.As a consequence... well, I'm with this feeling that we're replicating too much code (just a feeling).
Another possible approach would be to keep the listener in
calendar.html(its original place) and pass throughkeydownevent to each view, but I thought it'd be a little bit awkward.