-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
[pickers] Restructure props in MonthPicker
/ YearPicker
and DayPicker
#4814
[pickers] Restructure props in MonthPicker
/ YearPicker
and DayPicker
#4814
Conversation
These are the results for the performance tests:
|
@@ -20,9 +20,11 @@ | |||
"defaultCalendarMonth": { "type": { "name": "any" } }, | |||
"DialogProps": { "type": { "name": "object" } }, | |||
"disabled": { "type": { "name": "bool" } }, | |||
"disableFuture": { "type": { "name": "bool" } }, |
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.
I don't know why those props were not documented, they were already here in TS
}) !== null, | ||
[disableFuture, disablePast, maxDate, minDate, shouldDisableDate, utils], | ||
); | ||
const isDayDisabled = useIsDayDisabled({ |
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.
Just a small wrapper to be re-used in DayPicker
const selectedDate = date || now; | ||
const currentYear = utils.getYear(selectedDate); | ||
const wrapperVariant = React.useContext(WrapperVariantContext); | ||
const selectedYearRef = React.useRef<HTMLButtonElement>(null); | ||
const [focusedYear, setFocusedYear] = React.useState<number | null>(currentYear); | ||
|
||
const isYearDisabled = React.useCallback( |
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.
Copies from #4807
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 pull request has conflicts, please resolve those before we can evaluate the pull request. |
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 looks good
I had some difficulties with isMonthDisabled
because as it is I would imagine it checking "is January disabled?" but instead it checks "is January 1997 disabled?" but I'm not sure we can clarify this point
packages/x-date-pickers-pro/src/DateRangePicker/DateRangePicker.tsx
Outdated
Show resolved
Hide resolved
packages/x-date-pickers/src/internals/hooks/validation/useTimeValidation.ts
Show resolved
Hide resolved
I guess you can have use cases where you want to disable January in all years and use cases where you want to disable January just in one year |
MonthPicker
/ YearPicker
and DayPicker
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Do you need a review or do you have stuff to add in this PR? |
I think I'm good for a review 👍 |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
return 'maxDate'; | ||
|
||
default: | ||
return null; | ||
} | ||
}; | ||
|
||
export const useIsDayDisabled = <TDate>({ |
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.
Should we put in this file all the validations (adding month and year validation)
Such that in this folder we test the edge cases, and in components only do one test to check diasble has been applied to the component
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.
Yes I think it would be a good idea to move all date-related validations in the validation
folder
In the future
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 looks good
Goal
Have
MonthPicker
/YearPicker
/DayPicker
usable in a standalone way. They should not rely on abstractions inCalendarPicker
and they should have a coherent API when used alone (no required prop that could be nullable for instance).Avoid JSDoc duplication for documented props like
disablePast
, it leads to inconsistent descriptions / default value.Work
Packages
Create new centralized interfaces
DayValidationProps
,MonthValidationProps
,YearValidationProps
to avoid defining props likeshouldDisableMonth
ordisablePast
in several interfaces with inconsistent descriptions.Remove
onMonthChange
prop fromMonthPicker
as it is equivalent toonChange
and instead wrap theonChange
passed toMonthPicker
fromCalendarPicker
to callonMonthChange
.Remove
onYearChange
prop fromYearPicker
as it is equivalent toonChange
and instead wrap theonChange
passed toYearPicker
fromCalendarPicker
to callonYearChange
.When changing year, do not go to the closest non-disabled date in
YearPicker
but inCalendarPicker
becauseYearPicker
should not care about the availability of days inside the year.When changing month, go to the closest non-disabled date in
CalendarPicker
(was not done at all)Remove the
isDateDisabled
prop fromYearPicker
andMonthPicker
and instead addmaxDate
/minDate
/disableFuture
/disablePast
to be able to use those components standalone instead of relying on an outside abstraction.Apply default
minDate
/maxDate
directly in the validation function to avoid missing it in some componentsTests
minDate
/maxDate
inYearPicker
andMonthPicker
What's next
Clarify why on
CalendarProps
we sometime spreadother
and / orcalendarState
. It makes it difficult to follow props and I don't think the sub-components have enough props to justify those spreads.Move the Sub-components section into standalone pages for
YearPicker
,MonthPicker
andDayPicker
Breaking change
The props of
MonthPicker
/YearPicker
andDayPicker
have been reworked to make them more consistent for a standalone usage ([pickers] Restructure props inMonthPicker
/YearPicker
andDayPicker
#4814) @flaviendelangleMonthPicker: The prop
onMonthChange
has been removed, you can useonChange
instead since every change is a month changeYearPicker: The prop
onYearPicker
has been removed, you can useonChange
instead since every change is a year changeDayPicker: The prop
isDateDisabled
has been removed, you can now use the same validation props as for the other components (maxDate
,minDate
,shouldDisableDate
,disableFuture
anddisablePast
)