[pickers] The value prop is not correctly typed

[aqeelat]

Steps to reproduce

Link to live example: https://stackblitz.com/edit/github-gm5jav

It is very hard to create a shareable repro, but the component could be a simple <DatePicker value={new Date()} />

Current behavior

value only accepts null or undefined

Expected behavior

To have the correct type

Context

It is very hard to create a shareable repro, but the issue is that we have a monorepo with a couple of react apps, and a separate package for our common stuff such as ui elements and forms, some of which have DatePickers.

However, because we're not surrounding our shared components with a LocalizationProvider, the type for DatePicker.value becomes never. (but the packages that use them do actually have LocalizationProviders that are setup correctly)

Your environment

npx @mui/envinfo

  System:
    OS: macOS 15.0
  Binaries:
    Node: 21.7.3 - ~/.nvm/versions/node/v21.7.3/bin/node
    npm: 10.5.0 - ~/.nvm/versions/node/v21.7.3/bin/npm
    pnpm: Not Found
  Browsers:
    Chrome: 129.0.6668.70
    Edge: Not Found
    Safari: 18.0

Search keywords: datepicker type value

[flaviendelangle]

Hi,

You should be able to fix your problem using this doc section

[flaviendelangle]

@LukasTy if this is doable, would you be in favor of typing the date to any when there is no date type registered for PickerValidDate?
That way, the fallback is any instead of never which is probably less brutal 😆

EDIT: It seems to work

[aqeelat]

This solved it! Thank you.

I suggest making this doc more prominent. Maybe making typescript a top level document.

[LukasTy]

LukasTy if this is doable, would you be in favor of typing the date to any when there is no date type registered for PickerValidDate?
That way, the fallback is any instead of never which is probably less brutal 😆

Oh, shoot. 🙈
Well, that would clearly be much better for such use cases. 👍 💯

[flaviendelangle]

The main downside is that people won't discover how to actually get the correct typing.

People with a classic setup will have a correct typing like today
People with a setup that currently throw an error will just have any and will probably stay with any.

Not sure how to get the best of both worlds though...

[LukasTy]

The main downside is that people won't discover how to actually get the correct typing.

Yes, that is not an ideal downside, but I think that fallback is still better than a case where you can hardly avoid the error.
I think that users, who care about correct typing will take the time to investigate how to apply it, but we will unblock those, who are fine with not the most ideal solution.
WDYT? 🤔

Not sure how to get the best of both worlds though...

I don't think we can, given how the typing is setup and the various use cases that users might have. 🤷

[flaviendelangle]

I also think any is better than an error where most people have to create a Github issue because it's hard to find an answer by yourself on the doc.

Maybe we could just add one line in the JSDoc of the value prop (not the other props) saying that "if you have any as the date type here, please look at this doc section.
Other than that I don't have ideas.

[LukasTy]

Maybe we could just add one line in the JSDoc of the value prop (not the other props) saying that "if you have any as the date type here, please look at this doc section.
Other than that I don't have ideas.

Yes, I came to the same solution. Steer users to the documentation on how to fix it. 🤔 🙈

[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.

Note

We value your feedback @aqeelat! How was your experience with our support team?
We'd love to hear your thoughts in this brief Support Satisfaction survey. Your insights help us improve!