upgrade to react-day-picker v5 #1014
Conversation
|
oh wait we're probably going to need a fix in DT for this... |
|
waiting on DefinitelyTyped/DefinitelyTyped#16010 to fix DT issue blocking build. current typings are incorrect. |
|
I wonder if we can get r-d-p to bundle .d.ts, filed gpbl/react-day-picker#299 |
|
I think you're now unblocked with r-d-p v5.3.0 |
remove NPM types cuz they ship in the package now
[email protected]Preview: documentation |
|
@adidahiya @cmslewis looking good here! builds perfectly with latest r-d-p release. |
| @@ -20,7 +20,8 @@ export interface IDatePickerCaptionProps { | |||
| onYearChange?: (year: number) => void; | |||
|
|
|||
| // normally we could extend ReactDayPicker.CaptionElementProps, | |||
| // but we don't want to introduce a typing dependency, so manually add props here | |||
| // but we don't want to introduce a typing dependency, so manually add props here. | |||
There was a problem hiding this comment.
aha so this is no longer a problem! we can use types from react-day-picker because our consumers will be able to resolve them without installing an additional @types package. let's try to extend CaptionElementProps here (there's no rush for this PR as-is).
There was a problem hiding this comment.
oh snap wow sounds like fun!
There was a problem hiding this comment.
i'm gonna merge this PR and clean up the types separately
edit: nevermind, i did the types and they are awesome!
| @@ -13,7 +13,8 @@ export interface IDatePickerLocaleUtils { | |||
| formatWeekdayShort: (weekday: number, locale: string) => string; | |||
| formatWeekdayLong: (weekday: number, locale: string) => string; | |||
| getFirstDayOfWeek: (locale: string) => number; | |||
| getMonths: (locale: string) => string[]; | |||
| // tslint:disable-next-line:max-line-length | |||
| getMonths: (locale: string) => [string, string, string, string, string, string, string, string, string, string, string, string]; | |||
There was a problem hiding this comment.
nit: Would prefer to give this type a clearer name. When I first saw this, I had to count the number of strings before I understood what this was.
There was a problem hiding this comment.
this is re-exported from ReactDayPicker itself; we cannot change the name. #1014 (comment) will actually allow me to remove this type entirely
IDatePickerLocaleUtils => RDP.LocaleUtils IDatePickerDayModifiers => RDP.DayModifiers
use SFC syntax for `captionElement` prop to receive props to inject!
IDatePickerCaptionProps extends ReactDayPicker.CaptionElementPropsPreview: documentation |
| @@ -7,13 +7,20 @@ | |||
|
|
|||
| import * as classes from "./common/classes"; | |||
|
|
|||
| // re-exporting these symbols to preserve compatility | |||
| disabledDays={this.disabledDays} | ||
| enableOutsideDays={true} | ||
| fromMonth={minDate} | ||
| initialMonth={new Date(displayYear, displayMonth)} |
There was a problem hiding this comment.
this got renamed? the new prop name seems less intuitive... but ok
There was a problem hiding this comment.
this initialMonth prop was changed to behave like an uncontrolled defaultValue and a month prop was added for the controlled counterpart, which is what we were using the prop for. gpbl/react-day-picker#169
Merge branch 'master' of github.com:palantir/blueprint into gg/r-d-p-5Preview: documentation |
Fixes #688, Fixes #991
Changes proposed in this pull request:
@types/react-day-pickerdependency. now that types ship with the package itself, we can use them safely in our APIs because consumers will have them available.Reviewers should focus on:
initialMonthwill not show anymore a different month after the first mount (initialMonth should not update after first mounted gpbl/react-day-picker#169) ⇒ usemonthprop instead since we want to control the visible month.[Date, Date]tuple.DateUtilsimpls with r-d-p's ownclassNamesprop rather than re-using original class names (and disabling stylelint rules along the way)