Skip to content

refactor(datepicker): move keyboard events handlers into the views - #9775

Merged
jelbourn merged 6 commits into
angular:masterfrom
julianobrasil:refacDatePicker2
Feb 18, 2018
Merged

refactor(datepicker): move keyboard events handlers into the views#9775
jelbourn merged 6 commits into
angular:masterfrom
julianobrasil:refacDatePicker2

Conversation

@julianobrasil

@julianobrasiljulianobrasil commented Feb 4, 2018

Copy link
Copy Markdown
Contributor

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

<tableclass="mat-calendar-table"><theadclass="mat-calendar-table-header"><tr><th*ngFor="let day of _weekdays" [attr.aria-label]="day.long">{{day.narrow}}</th></tr><tr><thclass="mat-calendar-table-header-divider" colspan="7" aria-hidden="true"></th></tr></thead><tbodymat-calendar-body[label]="_monthLabel"
[rows]="_weeks"
[todayValue]="_todayDate"
[selectedValue]="_selectedDate"
[labelMinRequiredCells]="3"
[activeCell]="_dateAdapter.getDate(activeDate) - 1"
(selectedValueChange)="_dateSelected($event)"
(keydown)="_handleCalendarBodyKeydown($event)"><-------HEREISTHELISTENERNOW</tbody></table>

Also, I thought it'd be better to move the a11y tests from calendar.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 through keydown event to each view, but I thought it'd be a little bit awkward.

@googlebotgooglebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Feb 4, 2018
@julianobrasiljulianobrasil changed the title refac(datepicker): move keyboard hanlders into the viewsrefacor(datepicker): move keyboard hanlders into the viewsFeb 4, 2018
@julianobrasiljulianobrasil changed the title refacor(datepicker): move keyboard hanlders into the viewsrefactor(datepicker): move keyboard hanlders into the viewsFeb 4, 2018
@julianobrasiljulianobrasil changed the title refactor(datepicker): move keyboard hanlders into the viewsrefactor(datepicker): move keyboard events handlers into the viewsFeb 4, 2018

@mmalerbammalerba left a comment

Copy link
Copy Markdown
Contributor

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

Comment threadsrc/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();

Copy link
Copy Markdown
Contributor

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

Copy link
Copy Markdown
ContributorAuthor

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. 😃

Comment threadsrc/lib/datepicker/month-view.ts Outdated
}

/** Focuses the active cell after the microtask queue is empty. */
_focusActiveCell() {

Copy link
Copy Markdown
Contributor

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?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea.

Comment threadsrc/lib/datepicker/month-view.ts Outdated
this._userSelected();
}

_userSelected(): void {

Copy link
Copy Markdown
Contributor

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()

@mmalerbammalerba added the target: major This PR is targeted for the next major release label Feb 15, 2018

@mmalerbammalerba left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

needs rebase

Comment threadsrc/lib/datepicker/calendar-body.ts Outdated
@Output() readonly selectedValueChange: EventEmitter<number> = new EventEmitter<number>();

constructor(private _elementRef: ElementRef,
private _ngZone: NgZone) {

Copy link
Copy Markdown
Contributor

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?

Comment threadsrc/lib/datepicker/month-view.ts Outdated
this._init();
}
if (this._dateAdapter.compareDate(oldActiveDate, this._activeDate)) {
this.activeDateChange.emit(this._activeDate);

Copy link
Copy Markdown
Contributor

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)

@julianobrasiljulianobrasilFeb 16, 2018

Copy link
Copy Markdown
ContributorAuthor

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.

@mmalerbammalerba added pr: lgtm action: merge The PR is ready for merge by the caretaker labels Feb 16, 2018
@jelbourn
jelbourn merged commit 8e3ab8d into angular:masterFeb 18, 2018
@julianobrasil
julianobrasil deleted the refacDatePicker2 branch March 30, 2018 11:07
devversion added a commit to devversion/material2 that referenced this pull request Sep 4, 2018
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).
devversion added a commit to devversion/material2 that referenced this pull request Sep 4, 2018
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).
devversion added a commit to devversion/material2 that referenced this pull request Sep 4, 2018
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).
jelbourn pushed a commit that referenced this pull request Sep 5, 2018
…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).
@angular-automatic-lock-bot

Copy link
Copy Markdown

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-botangular-automatic-lock-botBot locked and limited conversation to collaborators Sep 8, 2019
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

action: mergeThe PR is ready for merge by the caretakercla: yesPR author has agreed to Google's Contributor License Agreementtarget: majorThis PR is targeted for the next major release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

@julianobrasil@mmalerba@jelbourn@googlebot