[CalendarPicker] Don't move to closest enabled date when props.date contains a disabled date

[flaviendelangle]

Fixes #4705 for master (equivalent of #6146)

[mui-bot]

These are the results for the performance tests:

Test case	Unit	Min	Max	Median	Mean	σ
Filter 100k rows	ms	503.4	1,055.2	555.8	697.82	207.351
Sort 100k rows	ms	592.5	1,027	1,027	888.32	168.71
Select 100k rows	ms	150.7	302.5	276.8	249.76	54.28
Deselect 100k rows	ms	141.6	233.7	186.3	181.88	34.546

Generated by 🚫 dangerJS against fa95fb7

[traverse]

Hello, this actually caused some tests to fail on my end. I'm wondering why this wasn't considered a breaking change?

[flaviendelangle]

It was considered a bug fix because the existing behavior could lead to UI freeze.

[traverse]

Thanks for your reply @flaviendelangle.

I can understand that this was considered a bugfix but this was existing behavior that people might've been relying on like I did. The fix on my end was pretty straightforward but I can imagine it also breaking things for other people.

I'm not sure how strictly MUI adheres to semver and I don't want to be pedantic about it but I would consider this a breaking change even if it was a bugfix.

[flaviendelangle]

We could probably have added a temporary prop until v6 to opt-out of the behavior instead of removing it altogether, you are right

[Aerophite]

What was the rationale behind removing this? Removal of this behavior has really messed up my application as we relied on this happening. Any suggestions on how to get this effect without me having to create all the logic myself? I tried importing your internals directly (which I don't really want to do) but that doesn't work since my project is in CRA and Jest within it can't import ESM scripts...

Seems like this should have been an optional opt-in/out prop rather than a removal. And not just a temporary prop for removal later.

[flaviendelangle]

Hi,

Could you describe why this removal broke your application ?
We could add it back as an opt-in option with a warning saying that if the closest enable date is fare away, it will have terrible performances.

[Aerophite]

We have multiple date pickers within multiple rows of a table that, when you select dates in other rows, disables dates for rows that will be created later. In some instances, this means that we disable entire months at a time in the past/future as well as "today". We were relying on this to switch, if "today" is disabled, move to the next available non-disabled date.

For example, if we disabled the past and this month, we'd have wanted it to select the first day of the next month.

---

We are perfectly fine with the potential performance hit when using the feature with far-away dates.

[flaviendelangle]

In the past, the switch occurred when opening the picker.
Is this the intended behavior for you ?
Would it make sense to move to the closest enabled date on the picker's mount instead ?

[Aerophite]

We are only relying on it happening when the picker is opened. We wouldn't want it on mount since we would want to display previously input values, even if they are disabled now. For example, if we selected a date previously that is now disabled, we wouldn't want that date to now start changing.