mui / mui-x

MUI X: Build complex and data-rich applications using a growing list of advanced React components, like the Data Grid, Date and Time Pickers, Charts, and more!
https://mui.com/x/
4.07k stars 1.26k forks source link

[pickers] Allow better date picker customization #14376

Open shadaxv opened 2 weeks ago

shadaxv commented 2 weeks ago

Summary

What happened, MUI? You used to be great, transitioning towards headless hooks and providing a separate UI layer for components, making the library increasingly customizable. Yet now, more demanding developers are continuously facing setbacks. Is it really that difficult to maintain the level of customizability developers expect?

Certain simple features like allowing the pasting of dates in different formats have been open for months, even years. Why can't you expose a single prop to enable handling this by developers? It's possible to work around this, but no one officially documents it. Developers have to discover it themselves, and you will likely block those workarounds soon, as TextField.inputProps are already showing deprecation warnings for date pickers.

The way you're hardcoding components is very frustrating. I recently wanted to change the date input behavior to allow entering incorrect dates (as it was possible in v.5). For instance, if someone mistakenly enters "15" in the month field, it is changed to "5". It should remain "15" and display an error (as with v5) or should be removed (fine enough) or replaced with "12" rather than "5" (as with native date inputs), it is unintuitive. However, it seems you know better what users expect (but our users are extremely frustrated with the input behavior), and you have your magical logic for adjusting values deeply hardcoded, which does not work as native date input and there is no way to override that.

In the simplest variant, which would take only a few minutes to implement, it would be enough to ensure that there is a props to disable certain behaviors that are not customizable, and in an ideal world, there should be props that would allow you to apply your own logic in certain cases. At this point, if someone wants to have their logic in a date input, they have to write their own input and add a calendar next to it, but going down that road, why use a UI library at all if simple behavior is impossible to change and you have to write everything yourself?

I know you have more serious issues on your mind, I just want to show the problem and what many developers don't talk about because they just accept it for what it is, but this library just goes in the wrong direction

Examples

Simply overriding onPaste is a hassle - of course, you can't just pass onPaste because it's ignored. Instead, you have to create your own handler like handlePaste.

const CustomTextField = (props) => {
  const {
    handlePaste,
    ...textFieldProps
  } = props;

  return (
    <TextField
      {...textFieldProps}
      inputProps={{
        ...textFieldProps.inputProps,
        onPaste: handlePaste,
      }}
    />
  );
};

const DateInput = () => {
  const [value, setValue] = useState(null);

  const handlePaste = (event) => {
    event.stopPropagation();
    event.preventDefault();
    const dateToPaste = event.clipboardData.getData("text");

    const date = moment(dateToPaste, [
      "M/D/YYYY",
      "MM/DD/YYYY",
      "DD MMM YYYY",
      "DD MMMM YYYY",
      "YYYY-MM-DD",
      "YYYY-M-D",
      "YYYY.MM.DD",
      "YYYY.M.D",
      "DD.MM.YYYY",
      "D.M.YYYY",
      "YYYY/MM/DD",
      "YYYY-MM-DD",
    ]).format("MM/DD/YYYY");

    if (date !== "Invalid date") {
      setValue(moment(date));
    }
  };

  return (
    <DesktopDateTimePicker
      slots={{
        textField: CustomTextField,
      }}
      value={value}
      slotProps={{
        textField: {
          handlePaste,
        },
      }}
    />
  );
};

Motivation

Extremely frustrated users

Search keywords: datepicker, picker, date input

michelengelen commented 2 weeks ago

Hey @shadaxv ... thanks for opening this issue. I do understand your intention and I have forwarded this to the team to open up discussions around this. I know that we aim to align the best as possible with the native date picker behavior, so some of the mentioned limitations come from that.

I will add this to the board for now and see if we can somehow improve DX on it. 👍🏼