[pickers] Remove PickersTextField API?

[oliviertassinari]

Steps to reproduce

1. Open https://mui.com/x/react-date-pickers/custom-field/

Current behavior

We have custom pickers API: https://mui.com/x/react-date-pickers/custom-field/#using-material-pickerstextfield. The APIs look backward. If I have a custom TextField, I should be able to provide it, and once I can do this, PickersTextField seems to serve no purpose.

Expected behavior

We remove this API?

Instead, we show how to use existing input APIs, either TextField from Material UI: https://mui.com/x/react-date-pickers/custom-field/#using-material-textfield or a raw <div>/<input> https://mui.com/x/react-date-pickers/custom-field/#usage-with-an-unstyled-input

Context

I don't understand the purpose of the PickersTextField API. At first glance, it looks like a footgun. I'm expecting an API like https://mui.com/material-ui/react-autocomplete/. There seems to be nothing more intrinsically complex in a picker than in a select or a combo box to implement, so why can't we remove this?

Relative to #14496

I landed here from mui/material-ui#44631, because we have this code:

mui-x/packages/x-date-pickers/src/PickersTextField/PickersOutlinedInput/Outline.tsx

Line 118 in 659dc5f

<OutlineLabel className="notranslate">&#8203;</OutlineLabel>

which felt: "what?"

Your environment

v7.23.0

[flaviendelangle]

We are migrating away from the TextField DOM structure in favor of a DOM structure where each section is a DOM element. If you look at the DOM structure of PickersTextField, it does not render an <input />.
This is needed to have good accessibility, to avoid hacks on the focus management and this is what competitors like React Aria are doing.

There seems to be nothing more intrinsically complex in a picker than in a select or a combo box to implement, so why can't we remove this?

The keyboard editing is way more complex on the picker than it is on the select or on the autocomplete.
You can select a single section, you can edit with the arrows, etc...

PickersTextField is a temporary API to match as much as possible with the TextField API (since both are available during the migration phase).
In v9 it will be deprecated in favor of a new composition-based API that will let people build their own UI for the field while keeping our editing mechanism.

The migration is as follow:

• V7.0:

  • We introduce the new accessible DOM structure as opt-in.
  • We create a PickersTextField component that is the default UI used in the field and we make it public so that people can continue to do wrappers around the default component if they want to provide default props.

• V8.0

  • We make the accessible DOM structure opt-out

• V8.X

  • We release a new composition-based customization API that follows the Base UI DX to create a custom field that follows the accessible DOM structure
  • We deprecate the legacy DOM structure (that uses a TextField or any input-based component)

• V9.0

  • We remove the legacy DOM structure
  • We rework PickersTextField to use the new composition-based API under the hook (if this is too much of a breaking change we can keep the old PickersTextField as well for one major to help the migration).
  • We deprecate the textField slot for the fields and for the pickers. People can use slotProps.field / slots.field directly

• V10.0

  • We remove the textField slot

The migration is super long but this part of the UI is so central that I don't see how we could have moved faster :/

[github-actions]

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.

[flaviendelangle]

Now that we are in the middle of the migration, I think the only way we could have made it smoother would have been:

1. To entirely split useField and do the branching at the component level(have a Date Field component for the old DOM structure and a DateField componet for the new DOM structure. That way the new Date Field component wouldn't have a textField slot and we wouldn't have had to cary this abstraction for 2 additional years on the new DOM structure).
2. To go for the composition API instead of PickersSectionList from day one with the new DOM structure. But we didn't have Base UI at all at the time and I did not explore composition enough on my side.

You can find an unfinished proposal for the new DX to build a custom field here.

But to be honest, doing migration like that while making sure we are staying consistent with the @mui/material when we have no idea what they will do in a few months is a pain.