Skip to content
This repository has been archived by the owner on Dec 8, 2022. It is now read-only.

Datepicker enhancements #29

Merged
merged 9 commits into from
Apr 8, 2019
Merged

Conversation

Blackbaud-SteveBrush
Copy link
Member

@Blackbaud-SteveBrush Blackbaud-SteveBrush commented Apr 2, 2019

  • Removed requirement for template reference variable on wrapping datepicker component.
  • Reduced number of onChange calls when datepicker value is changed.
  • Created a datepicker test module.
  • Added visual test for invalid state.
  • Fixed calendar component to respect asynchronous selectedDate assignments.
  • Fixed datepicker AbstractControl to set appropriate values for dirty, touched, and invalid.
  • General code cleanup to respect code style guidelines.

@codecov
Copy link

codecov bot commented Apr 2, 2019

Codecov Report

Merging #29 into master will not change coverage.
The diff coverage is 100%.

Impacted file tree graph

@@          Coverage Diff          @@
##           master    #29   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files          17     17           
  Lines         748    788   +40     
  Branches      132    143   +11     
=====================================
+ Hits          748    788   +40
Impacted Files Coverage Δ
...ic/modules/datepicker/datepicker-config.service.ts 100% <100%> (ø) ⬆️
...c/modules/datepicker/datepicker-input.directive.ts 100% <100%> (ø) ⬆️
.../public/modules/datepicker/datepicker.component.ts 100% <100%> (ø) ⬆️
.../datepicker/datepicker-calendar-inner.component.ts 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7c5371e...ad81ab2. Read the comment docs.

Copy link
Contributor

@Blackbaud-AlexKingman Blackbaud-AlexKingman left a comment

Choose a reason for hiding this comment

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

Great work. Mostly, I have some questions around changing the public properties.

@@ -419,6 +421,22 @@ describe('datepicker calendar', () => {

});

it('should handle setting selected date asynchronously', fakeAsync(function () {
Copy link
Contributor

Choose a reason for hiding this comment

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

I might be missing something obvious, but how is this asynchronous? Also, you do very similar things in previous tests - I'm not sure what's different about this test...

Copy link
Member Author

Choose a reason for hiding this comment

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

It's a badly named unit test. I'll update the name so it makes more sense.

this._startingDay = value;
}
@ViewChild(SkyDatepickerCalendarComponent)
private calendar: SkyDatepickerCalendarComponent;
Copy link
Contributor

Choose a reason for hiding this comment

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

This changed from public to private - was that intentional?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep! This is only useful to the internal workings of the datepicker component (and not being referenced anywhere else).


@ViewChild(SkyDropdownComponent)
public dropdown: SkyDropdownComponent;
Copy link
Contributor

Choose a reason for hiding this comment

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

Just checking - was removing this public property deliberate?

Copy link
Member Author

Choose a reason for hiding this comment

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

It was. It's not being accessed anywhere within the datetime library.


public dateSelected(newDate: Date) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Removing a public property. Is this deliberate?

Copy link
Member Author

Choose a reason for hiding this comment

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

This was renamed to onSelectedDateChange to match our style guidelines (it was only being called from the datepicker's template).


public setSelectedDate(newDate: Date) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Removing a public property. Is this deliberate?

Copy link
Member Author

Choose a reason for hiding this comment

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

I switched the public method to a setter field (public set selectedDate). It was only being used by the datepicker-input directive.


public setMinDate(_minDate: Date) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Re: setMinDate / setMaxDate. I see you removed these references from the directive's OnChanges, but these are still public properties. Was removing these deliberate?

Copy link
Member Author

Choose a reason for hiding this comment

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

It was; we're not documenting these methods, and I would argue that if someone is using these directly, it's not the intent of the API.

@Blackbaud-AlexKingman
Copy link
Contributor

Blackbaud-AlexKingman commented Apr 8, 2019

Also, do we have an issue to update the docs/demo with the API changes?

@blackbaud-johnly
Copy link
Contributor

I created blackbaud/skyux2-docs#399 to make sure we update the docs. ... Do we need another issue in the skyux2 repo for the demo?

@Blackbaud-AlexKingman
Copy link
Contributor

Blackbaud-AlexKingman commented Apr 8, 2019

@blackbaud-johnly thanks! Yes, I'd think so. We're deprecating a major part of how this API is used, so the demo should probably reflect that.

Copy link
Member

@Blackbaud-TrevorBurch Blackbaud-TrevorBurch left a comment

Choose a reason for hiding this comment

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

Initial thoughts

public ngOnChanges(changes: SimpleChanges): void {
if (changes.minDate) {
this.onValidatorChange();
this.datepickerComponent.minDate = this.minDate;

Choose a reason for hiding this comment

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

Is there a reason that we aren't just doing these things in the setters for the property? Seems like we could if we are going to the getters/setters for all of these properties.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good call.

import { Subject } from 'rxjs/Subject';

import { SkyDatepickerCalendarComponent } from './datepicker-calendar.component';

import {

Choose a reason for hiding this comment

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

Shouldn't our libraries be below rxjs in the import ordering.

Copy link
Member Author

Choose a reason for hiding this comment

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

@skyux is on the same "level" as rxjs. I'm going with alphabetical order based on that.

Choose a reason for hiding this comment

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

Ok. I have always went with Angular -> Third party libraries -> Blackbaud libraries -> internal things. But I also see your logic :) Not a huge deal.

} from '@angular/forms';

@Component({
selector: 'datepicker-visual',
templateUrl: './datepicker-visual.component.html'
})
export class DatepickerVisualComponent implements OnInit {
public selectedDate: Date = new Date('4/4/2017');
public disabled = false;

Choose a reason for hiding this comment

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

Should we have a blank line before these public variables?

Copy link
Member Author

Choose a reason for hiding this comment

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

I could go either way. We can come up with a style guide if you like.

Choose a reason for hiding this comment

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

I personally like the line break and feel like it is more consistent with our other styles; however, I wouldn't consider it a blocker.

@blackbaud-johnly
Copy link
Contributor

I created blackbaud/skyux2#2335 to update the demo.

Copy link
Member

@Blackbaud-TrevorBurch Blackbaud-TrevorBurch left a comment

Choose a reason for hiding this comment

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

LGTM

@Blackbaud-SteveBrush Blackbaud-SteveBrush merged commit 405f125 into master Apr 8, 2019
@Blackbaud-SteveBrush Blackbaud-SteveBrush deleted the datepicker-enhancements branch April 8, 2019 20:51
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants