Skip to content
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

Merged
merged 27 commits into from
May 25, 2022

Conversation

flaviendelangle
Copy link
Member

@flaviendelangle flaviendelangle commented May 9, 2022

Goal

  • Have MonthPicker / YearPicker / DayPicker usable in a standalone way. They should not rely on abstractions in CalendarPicker 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 like shouldDisableMonth or disablePast in several interfaces with inconsistent descriptions.

  • Remove onMonthChange prop from MonthPicker as it is equivalent to onChange and instead wrap the onChange passed to MonthPicker from CalendarPicker to call onMonthChange.

  • Remove onYearChange prop from YearPicker as it is equivalent to onChange and instead wrap the onChange passed to YearPicker from CalendarPicker to call onYearChange.

  • When changing year, do not go to the closest non-disabled date in YearPicker but in CalendarPicker because YearPicker 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 from YearPicker and MonthPicker and instead add maxDate / 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 components

Tests

  • Write test where we select a non disabled month but the day is disabled (should go to the closest non-disabled date)
  • Write test with minDate / maxDate in YearPicker and MonthPicker

What's next

  • Clarify why on CalendarProps we sometime spread other and / or calendarState. 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 and DayPicker

Breaking change

  • The props of MonthPicker / YearPicker and DayPicker have been reworked to make them more consistent for a standalone usage ([pickers] Restructure props in MonthPicker / YearPicker and DayPicker #4814) @flaviendelangle

    MonthPicker: The prop onMonthChange has been removed, you can use onChange instead since every change is a month change

    YearPicker: The prop onYearPicker has been removed, you can use onChange instead since every change is a year change

    DayPicker: The prop isDateDisabled has been removed, you can now use the same validation props as for the other components (maxDate, minDate, shouldDisableDate, disableFuture and disablePast)

@flaviendelangle flaviendelangle self-assigned this May 9, 2022
@mui-bot
Copy link

mui-bot commented May 9, 2022

These are the results for the performance tests:

Test case Unit Min Max Median Mean σ
Filter 100k rows ms 261.9 430.6 369.3 344.98 63.179
Sort 100k rows ms 435.8 873 786.3 700.9 159.236
Select 100k rows ms 101.1 201.7 173.2 165.96 34.619
Deselect 100k rows ms 125.3 211.6 192.7 173.88 37.689

Generated by 🚫 dangerJS against 11ed3d9

@@ -20,9 +20,11 @@
"defaultCalendarMonth": { "type": { "name": "any" } },
"DialogProps": { "type": { "name": "object" } },
"disabled": { "type": { "name": "bool" } },
"disableFuture": { "type": { "name": "bool" } },
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 don't know why those props were not documented, they were already here in TS

@flaviendelangle flaviendelangle added the component: pickers This is the name of the generic UI component, not the React module! label May 9, 2022
}) !== null,
[disableFuture, disablePast, maxDate, minDate, shouldDisableDate, utils],
);
const isDayDisabled = useIsDayDisabled({
Copy link
Member Author

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(
Copy link
Member Author

Choose a reason for hiding this comment

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

Copies from #4807

Copy link
Member

Choose a reason for hiding this comment

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

I let you add the "Fix #4806" in PR description, and I close #4807?

@github-actions
Copy link

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label May 10, 2022
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label May 10, 2022
Copy link
Member

@alexfauquette alexfauquette left a 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

@flaviendelangle
Copy link
Member Author

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

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
The good thing with the current isMonthDisabled is that you can do both

@flaviendelangle flaviendelangle marked this pull request as ready for review May 10, 2022 12:18
@flaviendelangle flaviendelangle changed the title [pickers] Restructure props in MonthPicker / YearPicker and DayPicker [pickers] Restructure props in MonthPicker / YearPicker and DayPicker May 10, 2022
@github-actions
Copy link

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label May 10, 2022
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label May 10, 2022
@github-actions
Copy link

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label May 17, 2022
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label May 17, 2022
@alexfauquette
Copy link
Member

Do you need a review or do you have stuff to add in this PR?

@flaviendelangle
Copy link
Member Author

I think I'm good for a review 👍

@github-actions
Copy link

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label May 20, 2022
return 'maxDate';

default:
return null;
}
};

export const useIsDayDisabled = <TDate>({
Copy link
Member

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

Copy link
Member Author

@flaviendelangle flaviendelangle May 25, 2022

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

Copy link
Member

@alexfauquette alexfauquette left a comment

Choose a reason for hiding this comment

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

It looks good

@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label May 25, 2022
@flaviendelangle flaviendelangle merged commit 36d662e into mui:master May 25, 2022
@flaviendelangle flaviendelangle deleted the view-validation-props branch May 25, 2022 13:56
alexfauquette pushed a commit to alexfauquette/mui-x that referenced this pull request Aug 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change component: pickers This is the name of the generic UI component, not the React module!
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants