[docs] renderInput migration to v6 unclear

[kirill-develops]

Duplicates

• [X] I have searched the existing issues

Related page

https://mui.com/x/migration/migration-pickers-v5/

Kind of issue

Unclear explanations

Issue description

attempting to refactor to v6 method. In migration URL, it suggests using componentsProp however it's depreciated according to VSCode. this is my original code:

 <TimePicker
          // ...
          renderInput={(props) => (
            <TextField
              {...props}
              onBlur={() => setFieldTouched(`${stepName}.time`, true, false)}
              helperText={errors[stepName]?.time}
              error={Boolean(errors[stepName]?.time)}
              required
              fullWidth
            />
          )}
        />

tried the following with no luck:

<DatePicker
          // ...
          TextField={{
            onBlur: () => setFieldTouched(`${stepName}.date`, true, false),
            helperText: `${errors[stepName]?.date}`,
            error: touched[stepName]?.date && Boolean(errors[stepName]?.date),
            required: true,
            fullWidth: true,
          }}
/>

as well as:

 <TimePicker
          // ...
          TextField={(props) => (
            <TextField
              {...props}
              onBlur={() => setFieldTouched(`${stepName}.time`, true, false)}
              helperText={errors[stepName]?.time}
              error={Boolean(errors[stepName]?.time)}
              required
              fullWidth
            />
          )}
        />

with no success of recreating same behaviour

Context 🔦

No response

[LukasTy]

Thank you for opening this issue! 🙏

In migration URL, it suggests using componentsProp however it's depreciated according to VSCode.

Yes, it is marked as deprecated, but it's not going anywhere during the current major, we plan to drop the components props only in v7. If you wish to use the new API, you can by no means do it, they are almost equivalent, except for the fact that slots has lowercase items, whereas components expect them in uppercase. You can also use the provided optional codemod to help you in migrating to the new API.

FYI: We also have an open PR investigating the feasibility of replacing components references in the migration doc with slots. 😉

In regards to the issue itself—you do not seem to be extending the functionality of the original TextField component, thus, on v6 you can probably get away with avoiding the component override and just passing the extra props you need via:

componentsProps={{
// or
slotProps={{
  textField: {
    onBlur: () => setFieldTouched(`${stepName}.time`, true, false),
    helperText: errors[stepName]?.time,
    error: Boolean(errors[stepName]?.time),
    required: true,
    fullWidth: true,
  }
}}

If you are still having issues, please provide a minimal reproduction example using a CodeSandbox or any similar tool so that we could better investigate your problem. 😉

[kirill-develops]

Thanks for the clarification, @LukasTy.

https://mui.com/x/api/date-pickers/date-time-picker/ in the API documentation above, I was unaware that slots were meant to nest under slotProps, and I thought they were to be treated as a prop.

Your code snippet fixed the problem immediately. Additionally, the new Field component works incredibly and my hats go off to you guys for the update.

Kudos!

[LukasTy]

https://mui.com/x/api/date-pickers/date-time-picker/ in the API documentation above, I was unaware that slots were meant to nest under slotProps, and I thought they were to be treated as a prop.

That's a really good observation, thank you. 👌 Including a small paragraph and/or example on how to use the slots in the API docs slots section probably wouldn't hurt. 🙈

Additionally, the new Field component works incredibly and my hats go off to you guys for the update.

Kudos!

It's really nice hearing such praises, we're glad that you are liking it and hope that the end-users will appreciate it as well. 🙌 The team does feel that the new field approach is way superior to the previously used masked approach. Of course, nothing is perfect, there are known and possibly unknown issues as well as new challenges that pop up because of the change, but for most users, it should provide an easier way of entering and manipulating dates. 🤞

I'm closing the issue as the main topic seems to be resolved. If you feel that we are still missing something—feel free to re-open it or create a different issue for a separate topic. 😉