-
Notifications
You must be signed in to change notification settings - Fork 6.8k
refactor(datepicker): move keyboard events handlers into the views #9775
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels much better to me, having logic for each of the views mixed into the calendar definitely felt wrong
src/lib/datepicker/month-view.ts
Outdated
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: indent continuation lines by 4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I didn't know that was the rule. 😃
src/lib/datepicker/month-view.ts
Outdated
this._userSelection.emit(); | ||
} | ||
|
||
/** Focuses the active cell after the microtask queue is empty. */ | ||
_focusActiveCell() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could we move this logic to the calendar table instead of repeating it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea.
src/lib/datepicker/month-view.ts
Outdated
this._userSelected(); | ||
} | ||
|
||
_userSelected(): void { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I don't think this needs to be its own function, this._userSelected()
is only a couple characters shorter than this._userSelection.emit()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
needs rebase
src/lib/datepicker/calendar-body.ts
Outdated
@@ -81,6 +83,10 @@ export class MatCalendarBody { | |||
/** Emits when a new value is selected. */ | |||
@Output() readonly selectedValueChange: EventEmitter<number> = new EventEmitter<number>(); | |||
|
|||
constructor(private _elementRef: ElementRef, | |||
private _ngZone: NgZone) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like this will fit on one line?
src/lib/datepicker/month-view.ts
Outdated
if (!this._hasSameMonthAndYear(oldActiveDate, this._activeDate)) { | ||
this._init(); | ||
} | ||
if (this._dateAdapter.compareDate(oldActiveDate, this._activeDate)) { | ||
this.activeDateChange.emit(this._activeDate); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.html
Also, I thought it'd be better to move the
a11y
tests fromcalendar.spec.ts
to 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 throughkeydown
event to each view, but I thought it'd be a little bit awkward.