-
-
Notifications
You must be signed in to change notification settings - Fork 32.6k
[DatePicker] Provide prop to customize the icons #23604
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
Comments
Yeah, it is reaaly legacy name. Should be nice to change in scope of |
keyboardIcon
prop
Would you like to open PR? |
Well it's not just about renaming the existing prop, but also about exposing new props for those two hard-coded icons. |
keyboardIcon
prop
Yeah so I propose these changes:
|
Sure, I can take a stab at this. I can't assign myself in GitHub, but stay tuned. |
Naming the prop after the icon content doesn't play well with this usage, where we'd end up with So perhaps |
Hmm really, |
The prop should be named after the icon's functionality/usage. The new name matches the `hideOpenPickerButton` prop. The documentation on the prop already matches this wording. Tested by verifying that the two affected demo pages still work and show the customized icon.
* Rename KeyboardIcon to CalendarIcon The icon components should be named after their content. * Rename `keyboardIcon` prop to `openPickerIcon` #1693 The prop should be named after the icon's functionality/usage. The new name matches the `hideOpenPickerButton` prop. The documentation on the prop already matches this wording. Tested by verifying that the two affected demo pages still work and show the customized icon. * Update lib/src/_shared/icons/CalendarIcon.tsx Co-Authored-By: Olivier Tassinari <[email protected]> Co-authored-by: Dmitriy Kovalenko <[email protected]> Co-authored-by: Olivier Tassinari <[email protected]>
Just like for the other one, I don't think we should name the props after the icon content. How about |
…ses #1693) To make the previously hard-coded icons configurable.
…ses #1693) To make the previously hard-coded icons configurable.
Regarding the resolution, I would suggest we go in the direction of #21453. Meaning a |
Duplicate of #23673 |
Uh oh!
There was an error while loading. Please reload this page.
The icons are currently hard-coded:
https://github.com/mui-org/material-ui/blob/29fbcceb44e851a3a856e42035f86865dacd1fcd/packages/material-ui-lab/src/internal/pickers/PickersToolbar.tsx#L98-L102
There is already a
keyboardIcon
prop, but that one controls the icon in the input adornment. I don't really understand why that prop has "keyboard" in its name. It does not show a keyboard on the icon. And one would click that button precisely when not using the keyboard but rather the mouse to input a date. I'd call that oneopenIcon
(by function) orcalendarIcon
(by icon content).The text was updated successfully, but these errors were encountered: