-
-
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] Fix am/pm buttons position and responsiveness #5149
Conversation
Netlify deploy previewNetlify deploy preview: https://deploy-preview-5149--material-ui-x.netlify.app/ Updated pagesNo updates. These are the results for the performance tests:
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
4d830fd
to
deb3974
Compare
ampmSelection: ['ampmSelection'], | ||
ampmLabel: ['ampmLabel'], |
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 naming (like most of the code) is taken from TimePickerToolbar
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
To test all to configuration I made a demo: https://codesandbox.io/s/nervous-robinson-05gnne?file=/demo.tsx To compare with the same demo based on the latest version |
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.
Great job! 🚀
Such an annoying issue finally fixed. 💪
I couldn't find any issues testing what I could think of. 😉
packages/x-date-pickers/src/DateTimePicker/dateTimePickerToolbarClasses.ts
Outdated
Show resolved
Hide resolved
...ages/x-date-pickers/src/internals/components/CalendarOrClockPicker/CalendarOrClockPicker.tsx
Outdated
Show resolved
Hide resolved
* If `true`, the toolbar will be visible. | ||
* @default `true` for mobile, `false` for desktop | ||
*/ | ||
showToolbar?: boolean; |
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.
Heads-up: This is going to conflict with #7498
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.
An initial idea was to show view switcher only if:
- There is view to swich (more than 1 time view)
- The swich is not already available in the toolbar
Since showToolbar
is not available any more, and using slotProps.toolbar.hidden
does not seem reliable (as a developer it would be strange that a slot props impact another one) I propose to go to the safest way: show the view swich even if there is a toolbar. Leading to the following argos diff
@LukasTy does it seems good for you?
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.
Since
showToolbar
is not available any more, and usingslotProps.toolbar.hidden
does not seem reliable (as a developer it would be strange that a slot props impact another one)
Hm. Why do you think like that? showToolbar
was being used to understand if this view switcher need to be shown, but the only thing that changed is the location this prop has moved to.
If we want/need the view switcher logic to depend on toolbar prop, I do not see much problem with it. 🤔
Maybe adding a mention about this relationship somewhere would be useful, but I don't know the best place for it. 🙈
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.
Note that this kind of scenario won't work well if we support the callback format at somepoint.
Because we would not have the ownerState
outside of the layout component, so we could not correctly resolve the toolbar.hidden
prop.
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 did not thaught about that edge case
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. |
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.
Looking great! 👌
Had another go after all the recent changes in API and couldn't find issues with it.
Looks like a great improvement and fixes the shortcoming of not having meridiem switcher in DateTimePickerToolbar
. 🙌
There are a few final issues to solve before we could merge this. 😉
FYI. Been using this sandbox as well as locale changes.
P.S. The PR title could probably benefit from an update as the PR does impact more than it mentions. 🙈
packages/x-date-pickers/src/DateTimePicker/DateTimePickerToolbar.tsx
Outdated
Show resolved
Hide resolved
<PickersToolbarButton | ||
disableRipple | ||
variant="subtitle2" | ||
data-mui-test="toolbar-am-btn" |
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.
Maybe avoid adding these props as long as we can avoid the need for them in tests? 🤔
@@ -74,6 +74,11 @@ export interface BaseDateTimePickerProps<TDate> | |||
* @default `utils.is12HourCycleInCurrentLocale()` | |||
*/ | |||
ampm?: boolean; | |||
/** | |||
* Display ampm controls under the clock (instead of in the toolbar). | |||
* @default true |
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 seems that this is actually the PR resolving the need to remove this TODO.
Could you sync with next
and make the necessary mentioned adjustment? 🤔
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 forget it was also fixing it. Just added the related issue in the description
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.
Leaving a few comments to finalize a few points. 😉
/** | ||
* Display ampm controls under the clock (instead of in the toolbar). | ||
* @default true | ||
* @default true on desktop, false on mobile |
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.
Could you please apply the following diff to actually make this work as mentioned here? 🤔
Because currently, this place overrides defaults coming from Static
, Desktop
, and Mobile
pickers. 🙈
diff --git a/packages/x-date-pickers/src/DateTimePicker/shared.tsx b/packages/x-date-pickers/src/DateTimePicker/shared.tsx
index 8bc182198..68e0c1910 100644
--- a/packages/x-date-pickers/src/DateTimePicker/shared.tsx
+++ b/packages/x-date-pickers/src/DateTimePicker/shared.tsx
@@ -129,7 +129,6 @@ type UseDateTimePickerDefaultizedProps<
| 'views'
| 'openTo'
| 'orientation'
- | 'ampmInClock'
| 'ampm'
| keyof BaseDateValidationProps<TDate>
| keyof BaseTimeValidationProps
@@ -163,7 +162,6 @@ export function useDateTimePickerDefaultizedProps<
};
}, [themeProps.localeText]);
- const ampmInClock = themeProps.ampmInClock ?? true;
const slots = themeProps.slots ?? uncapitalizeObjectKeys(themeProps.components);
const slotProps = themeProps.slotProps ?? themeProps.componentsProps;
return {
@@ -177,7 +175,6 @@ export function useDateTimePickerDefaultizedProps<
ampm,
localeText,
orientation: themeProps.orientation ?? 'portrait',
- ampmInClock,
// TODO: Remove from public API
disableIgnoringDatePartForTimeValidation:
themeProps.disableIgnoringDatePartForTimeValidation ??
@@ -205,7 +202,6 @@ export function useDateTimePickerDefaultizedProps<
...slotProps,
toolbar: {
ampm,
- ampmInClock,
...slotProps?.toolbar,
},
},
@@ -26,6 +26,11 @@ export interface DesktopDateTimePickerSlotsComponentsProps<TDate> | |||
export interface DesktopDateTimePickerProps<TDate> | |||
extends BaseDateTimePickerProps<TDate>, | |||
DesktopOnlyPickerProps<TDate> { | |||
/** | |||
* Display ampm controls under the clock (instead of in the toolbar). | |||
* @default true |
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.
Are you sure it's worth going with these overrides trying to provide a more correct default? 🤔
It's nice, I agree, but in that case, we'd need to fix an issue with DateTimePicker
, maybe omit ampmInClock
when creating DateTimePickerProps
?
Or just go without overriding the default and show true on desktop, false on mobile
🙈
What's your take on it @flaviendelangle?
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 did not realize it would also affect all the other component. I moved back to true on desktop, false on mobile
for every one to avoid side effects
Fix #4947
Fix #7279
Second part of #4446
Explanation commit by commit:
ampmInClock
is used to know if buttons are in there clock or the toolbar (not the appbar). So I rewrite theampmInClock
behavior as follow:ampmInClock
. Otherwise, end-users would not have access to ampmampmInClock
ampmInClock
to theToolbarComponent
MobileDateTimePicker
neither display the toolbar eithen ifshowToolbar
is set totrue
fixing that was asked in [pickers]getViewSwitchingButtonText
prop does not work #4446Before: with code | without code
After: with code | without code
Changelog
On desktop,
DateTimePicker
shows the ampm controls in the toolbar instead of the clock by default.It can be overridden by specifying
ampmInClock
prop.