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] Fix am/pm buttons position and responsiveness #5149

Merged
merged 23 commits into from
Mar 3, 2023

Conversation

alexfauquette
Copy link
Member

@alexfauquette alexfauquette commented Jun 8, 2022

Fix #4947
Fix #7279
Second part of #4446

Explanation commit by commit:

  1. ampmInClock is used to know if buttons are in there clock or the toolbar (not the appbar). So I rewrite the ampmInClock behavior as follow:
    • If there is no toolbar, ampm buttons are in the clock whatever is the value of ampmInClock. Otherwise, end-users would not have access to ampm
    • If there is a toolbar, ampm buttons are either in the toolbar or the clock (not both) according to ampmInClock
  2. I forgetted to propagate ampmInClock to the ToolbarComponent
  3. MobileDateTimePicker neither display the toolbar eithen if showToolbar is set to true fixing that was asked in [pickers] getViewSwitchingButtonText prop does not work #4446
  4. Add ampm control in the toolbar of MobileDateTimePicker
  5. Inverse the order between components such that the view switcher is over the clock which is stealing the click

Before: 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.

@mui-bot
Copy link

mui-bot commented Jun 8, 2022

Netlify deploy preview

Netlify deploy preview: https://deploy-preview-5149--material-ui-x.netlify.app/

Updated pages

No updates.

These are the results for the performance tests:

Test case Unit Min Max Median Mean σ
Filter 100k rows ms 707.3 1,155.8 707.3 943.84 188.625
Sort 100k rows ms 631.9 1,075.2 811.7 869.12 149.216
Select 100k rows ms 187.1 283.3 228.1 232.38 30.932
Deselect 100k rows ms 151.2 306.1 186 202.58 56.723

Generated by 🚫 dangerJS against 1addb5f

@alexfauquette alexfauquette added component: TimePicker The React component. design: ux dx Related to developers' experience component: DateTimePicker The React component. labels Jun 8, 2022
@alexfauquette
Copy link
Member Author

It still has one problem: the pen icon in the toolbar is at the same location as the view switcher of the clock
image

@flaviendelangle
Copy link
Member

image

On the DateTimePicker (both mobile and desktop) with both props true.

@alexfauquette
Copy link
Member Author

Strange because I do not manage to reproduce this issue which looks like an encoding one

image

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

github-actions bot commented Sep 1, 2022

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

@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Jan 3, 2023
Comment on lines 39 to 40
ampmSelection: ['ampmSelection'],
ampmLabel: ['ampmLabel'],
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 naming (like most of the code) is taken from TimePickerToolbar

@github-actions
Copy link

github-actions bot commented Jan 9, 2023

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 Jan 9, 2023
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Jan 9, 2023
@alexfauquette
Copy link
Member Author

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
https://codesandbox.io/s/gracious-edison-qs4mn8

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

@LukasTy LukasTy left a 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. 😉

* If `true`, the toolbar will be visible.
* @default `true` for mobile, `false` for desktop
*/
showToolbar?: boolean;
Copy link
Member

@LukasTy LukasTy Jan 16, 2023

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

Copy link
Member Author

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?

image

Copy link
Member

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 using slotProps.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. 🙈

Copy link
Member

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.

Copy link
Member Author

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

@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 Jan 17, 2023
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Jan 17, 2023
@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Jan 17, 2023
@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 PR: out-of-date The pull request has merge conflicts and can't be merged and removed PR: out-of-date The pull request has merge conflicts and can't be merged labels Jan 17, 2023
@github-actions
Copy link

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

@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Feb 14, 2023
@alexfauquette alexfauquette requested a review from LukasTy March 1, 2023 14:03
Copy link
Member

@LukasTy LukasTy left a 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. 🙈

<PickersToolbarButton
disableRipple
variant="subtitle2"
data-mui-test="toolbar-am-btn"
Copy link
Member

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

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? 🤔

Copy link
Member Author

@alexfauquette alexfauquette Mar 2, 2023

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

@alexfauquette alexfauquette changed the title [TimePicker] Fix ampm buttons position [pickers] Fix am/pm buttons position and responsiveness Mar 2, 2023
Copy link
Member

@LukasTy LukasTy left a 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
Copy link
Member

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

@LukasTy LukasTy Mar 3, 2023

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?
Screenshot 2023-03-03 at 09 42 16

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 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

@alexfauquette alexfauquette merged commit 4a08283 into mui:next Mar 3, 2023
@oliviertassinari oliviertassinari added design This is about UI or UX design, please involve a designer and removed design: ux labels Aug 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: DateTimePicker The React component. component: TimePicker The React component. design This is about UI or UX design, please involve a designer dx Related to developers' experience
Projects
None yet
5 participants