[DatePicker] StaticDatePicker doesn't honor disabled

[scottlamb]

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

StaticDatePicker doesn't appear to honor the disabled={true} attribute. It looks and behaves no differently (as far as I can tell) from when disabled is false or unspecified.

(As an aside, many of the attributes on https://next.material-ui.com/api/static-date-picker/ seem like they're not actually relevant to this component? eg the description for disableOpenPicker makes more sense for DatePicker than StaticDatePicker. I suspect a bunch of these are here by mistake, but I think disabled can and should do something.)

Expected Behavior 🤔

All the days should be grayed out; clicking on them should have no effect.

Steps to Reproduce 🕹

https://codesandbox.io/s/material-ui-issue-forked-nc8gdh?file=/Demo.js

Steps:

1. open and see it doesn't appear disabled
2. click on something and see it calls the callback

Context 🔦

(I initially filed this as mui/material-ui-pickers#2172 but moving this over from there after seeing the banner saying that older version is no longer maintained.)

My software's UI is oriented to selecting/viewing existing segments of video. It only makes sense to select dates in which there is video available. Sometimes there are no such dates, eg if there are currently no cameras selected to view or if recording is broken. I think a static date picker makes the most sense because which dates are available is information I don't want to hide behind a click. I also don't think it makes sense for the date picker to appear and disappear (and thus other UI elements jump) based on whether any selection is valid; I'd rather it just appear disabled.

In my existing (ancient jQuery UI-based) interface, the date picker looks like this when disabled:

That's roughly what I want to match in my React/material-ui-based UI rewrite.

Your Environment 🌎

Chrome Version 88.0.4324.150 (Official Build) (x86_64)

`npx @material-ui/envinfo`

  System:
    OS: macOS Mojave 10.14.6
  Binaries:
    Node: 14.15.4 - /usr/local/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.10 - /usr/local/bin/npm
  Browsers:
    Chrome: 88.0.4324.182
    Edge: Not Found
    Firefox: 84.0.2
    Safari: 14.0.3
  npmPackages:
    @emotion/react: latest => 11.1.5
    @emotion/styled: latest => 11.1.5
    @material-ui/core: next => 5.0.0-alpha.25
    @material-ui/lab: next => 5.0.0-alpha.25
    @material-ui/styled-engine:  5.0.0-alpha.25
    @material-ui/styles:  5.0.0-alpha.25
    @material-ui/system:  5.0.0-alpha.25
    @material-ui/types:  5.1.7
    @material-ui/unstyled:  5.0.0-alpha.25
    @material-ui/utils:  5.0.0-alpha.25
    @types/react:  17.0.2
    react: latest => 17.0.1
    react-dom: latest => 17.0.1
    typescript: latest => 4.1.5

[scottlamb]

I just realized what should have been obvious: mui/material-ui-pickers#1336 ("shouldDisableDate crushes DatePicker") has been fixed, so I can get basically the behavior I want by simply always returning true in shouldDisableDate. (And perhaps also setting minDate and maxDate to disable flipping through months.) I still think disabled should be honored, but the workaround is easy.

[MohitPopli]

I can reproduce this issue very well. I would love to contribute over this.

[michchan]

I can still reproduce similar issue with ^3.3.10.
Putting minDate and maxDate there but the disabled dates not displayed as it should be.

Found out upgrading @material/core from v4.2 to v4.12 works

[alexfauquette]

Sounds like this issue is solved. I moved the codesandbox to the new version and all the days appear light gray as expected

https://codesandbox.io/s/material-ui-issue-forked-0v1z9d?file=/src/demo.js

@scottlamb @michchan I am missing the bug?

[scottlamb]

Oh, great, that looks as I'd expect. I just replaced my codesandbox link at the top with one that renders with versions from when I filed the bug. (Looks like it'd rotted because I hadn't pinned versions, and somehow there was a case mismatch with demo.js, probably also my fault. It was my first time using codesandbox.) You can see the behavior change comparing the two now. So thanks to whoever fixed it between, and thank you @alexfauquette for checking now.