[pickers] Allow to refuse ranges that contains at least one disabled date

[bruns6077]

Steps to reproduce

Link to live example: Livedemo

Steps:

1. Define some Date you want to disable
2. Select a range which includes the disabled dates
3. You have successfully included them in your date-range, which should not be possible

Current behavior

When i define some Dates i want to disable (lets say we want to reflect some booking on the date-range picker)

I am still able to include them in my range by selecting a date before them and after them

Expected behavior

I would expect i can only select a range until a date is not disabled.

so lets assume the following:

10,14 Feb disabled: i would only be able to select 11,12,13 Feb

Basically if you select 11 Feb all dates except 12 and 13 need to be disabled so we can not select them until u made your selection.

1,2,3,5 Feb disabled: i would only be able to select 4 Feb

Basically if you select 4 Feb all dates except 12 and 13 need to be disabled so we can not select them until u made your selection.

i would suggest to implement it as an optional boolean which has its default value to true.

Context

this function is needed to be able to reflect booking mechanisms which much applications will need.

another thing which would be nice is a function for custom rendering days (maybe we want some certain dates to appear differently cause there are different events or prices) a possibility would be an render functions which kind of works like shouldDisableDate but does not only have the date as param, it should also include the component as param, and the handlers. so manipulation could be done. The function could Look Like this (date,component,handlers) => React.ReactElement

Your environment

No response

Search keywords: datepicker,timepicker,daterangepicker,picker,bug,ui,ux,booking mechanism, custom day rendering

[michelengelen]

@bruns6077 interesting use case indeed! @LukasTy do you know if we can support such behavior? I guess we could utilize the shouldDisabelDate method to define disabled days based on the currently selected (start-)range and the definitely disabled ones, but this can be potentially expensive. WDYT?

[bruns6077]

@michelengelen Yeah i think also that this could be expensive. But what about the custom day rendering then ?

[LukasTy]

Great suggestion for disabled dates behavior. Just one clarification - I believe that if we add a flag to control it, then this behavior should be turned off by default to avoid a breaking behavior change.

As for the custom day rendering, have you tried passing your own component to the day slot? 🤔

And for the current option to implement the requested custom behavior - yes, using shouldDisableDate seems like the single option at the moment. 🤷

I'm moving this issue to our board for grooming to discuss the disabled behavior extending. 😉

[flaviendelangle]

@LukasTy our discussion works great for DateRangePicker. But what about DateTimeRangePicker? We can't test every time in the range to check if some are disabled.

Would you be OK to only add the prop to DateRangePicker and think about the lower level API for the DateTimeRangePicker? Or should we re-evaluate our approach?

BTW the other issue solved by a lower level API like isRangeValid is #8868

[LukasTy]

It looks like we might be able to utilize a boolean to control the ability to select disabled dates just as some competitors do. The only difference is that we would need to add this boolean with inverse logic (disableNonContigousRanges) or something like that, to avoid a BC. As for the validation itself, it looks like shouldDisableDate should be enough to create the most complex examples.

As for #8868, we'd need some double-checking, but it would seem that a combination of shoulDisableDate and disableNonContigousRanges would also do the trick. 🤔

Naturally, if we see that the performance impact is undesirable, maybe going for a more lightweight solution like maxSpan here could be a good alternative.

As for the DateTimeRangePicker and TimeRangePicker—I wouldn't see a problem in them not supporting these features at first until we see requests for them.