[pickers] Improve customization for Buttons and Tabs across pickers

[bruns6077]

Steps to Reproduce

There is no live example available as the issue cannot be replicated in a live environment.

The current limitations significantly hinder the theming process for pickers. Reusing existing themes for tabs and buttons is not feasible, leading to only one alternative:

Apply custom classes to the root element (DesktopPaper or MobilePaper) and override the styles for action buttons and tab styles based on the rootClass. This method is inefficient as it involves duplicating styles due to the inability to modify the color property directly.

Reproduction Steps:

1. Initiate any Picker component (DatePicker, DateRangePicker, or DateTimePicker).
2. Attempt to alter the Button color through SlotProps (actionBar) - This is unsuccessful as only action strings can be provided, which is insufficient.
3. Attempt to modify the Tab color through SlotProps (tabs) - Currently unsupported (DateTimePicker).

Current Behavior

The PickersActionBarProps is currently defined as follows:

export interface PickersActionBarProps extends DialogActionsProps {
    /**
     * Ordered array of actions to display.
     * If empty, the action bar is not displayed.
     * @default `['cancel', 'accept']` for mobile and `[]` for desktop
     */
    actions?: PickersActionBarAction[];
    onAccept: () => void;
    onClear: () => void;
    onCancel: () => void;
    onSetToday: () => void;
}

With actions defined as: export type PickersActionBarAction = 'clear' | 'cancel' | 'accept' | 'today';

Expected Behavior

PickersActionBarProps should also accommodate ButtonProps, or at the very least, the color attribute. An improved definition could be:

export interface PickersActionBarProps extends DialogActionsProps {
    /**
     * Ordered array of actions to display.
     * If empty, the action bar is not displayed.
     * @default `['cancel', 'accept']` for mobile and `[]` for desktop
     */
    actions?: {
      action: PickersActionBarAction,
      props: ButtonProps, // Or a generic T for dynamic component rendering support
      component: string, // Optional, depending on implementation preferences. Supporting dynamic components may require a generic type for props.
    }[];
    onAccept: () => void;
    onClear: () => void;
    onCancel: () => void;
    onSetToday: () => void;
}

Additionally, TabProps should be included in SlotProps for the DateTimePicker.

Context

The current framework does not support styling Picker tabs and button colors (actionBar), posing a challenge for customization.

Your Environment

Not provided.

Search Keywords: timepicker, pickers, datepicker, rangepicker, daterangepicker, colors, props

[michelengelen]

@LukasTy looks like a good enhancement ... will put this on the board.

[LukasTy]

@bruns6077 Thank you for creating this issue.

In regards to PickersActionBar, what do you think about building your own component? It is a very minimal component and IMHO, the option to pass a custom component will have more freedom than any additional API that we can add. 🤔

As for the Tabs component, indeed, there is no way to pass even sx currently and that is a known shortcoming. However, we already have https://github.com/mui/mui-x/issues/11532 to take care of it. Would it cover your needs? Or is your need specifically to have the option to provide a color prop to those buttons to benefit from the built-in background and text color behavior? 🤔

[bruns6077]

@LukasTy

hey, building your own component is no option i have tested it yesterday, i will edit my initial post. ( with custom component we are still limited to the same stuff we would have in the pre defined ready-to-use picker component regarless of its type (timePicker, datePicker etc.))

so what is needed is the following :

for actions and tabs:

pass the color prop to benefit from defined color theming

for actions (optional):

dynamic component rendering, maybe we dont want to render a button but maybe we want to render a IconButton or even something else, another possibility would also be to provide a placeholder action which takes a function argument where we can exactly do this but with the ability to hook into existent onClick handlers like onCancel etc.

and some other optional stuff would be:

passing color prop to the picker itself and reflect it on the picker dialog or paper, currently i am manually adding it over classNames

[LukasTy]

@bruns6077 Could you confirm if this is something you are trying to achieve? It seems doable by overriding the tabs and toolbar slots, but I can confirm that we can and will do better in this regard. 👌 I was just trying to see if there is a way to "unblock" you while we implement a more extensive customization solution out of the box. 😉

[bruns6077]

@LukasTy yes i can confirm that i am trying to achieve something like that. currently i have a workaround (based on the dialog class i have overridden the tabs and buttons with already defined styling for them so currently i have duplicated code in my theme file) will remove this part once this feature is included. well overriding the slots would mean also to override the handlers and defining them. in my opinion the ready-to-use one is very nice and customizable but it has lack of props atm.

btw:

i created another enhancement ticket which could also have high priority: 12072

[bruns6077]

another enhancement ticket i created:

12075

with this 3 enhancement we have a really solid base of customization and realization of complex booking mechanisms or other mechanisms

[LukasTy]

During the grooming, we decided to start by providing a better complete example of overriding the actionBar slot. Given the size of the component, we think, that it makes more sense to advocate for an approach with the most freedom. To achieve that, we'll need to move the useLocaleText hook to public API to have the option of achieving an implementation on par with the default one. In addition to that, we decided to provide another docs example, where we'd change the layout (i.e. move one button to the left of other actions) and change the color and/or variant of specific buttons.

In regards to the concern of the need to redefine action handlers, it would not be needed, they are only being passed down to the respective buttons as seen here: https://github.com/mui/mui-x/blob/7d1b27f054e533ee130f526f643a55af0d3ad5cb/packages/x-date-pickers/src/PickersActionBar/PickersActionBar.tsx#L45

[kealjones-wk]

As mentioned by @LukasTy

To achieve that, we'll need to move the useLocaleText hook to public API to have the option of achieving an implementation on par with the default one.

Without useLocaleText or any of the hooks in that file, it makes it substantially harder to just build your own component to replace these.

[LukasTy]

We are closing this one in favor of https://github.com/mui/mui-x/issues/12691.

[github-actions[bot]]

:warning: This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue. Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.

@bruns6077: How did we do? Your experience with our support team matters to us. If you have a moment, please share your thoughts in this short Support Satisfaction survey.