[pickers] Enhancing Date Range Selection: Enforcing Disabled Dates and Custom Day Rendering in Date Pickers

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

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.

[dlsso]

@LukasTy or other team member: I want something like this as well, but I think the idea in this stack overflow question I found might be better (can see which dates are actually disabled, less calculation).

My question for you is, is there any way I can do that with the current range picker? I expected that to be the default behavior, but I don't see an option in the docs.

If the feature doesn't exist maybe I could do some onChange end date, create a list of values using start date, run all those through the shoulDisableDate function, and throw a validation error if there's a hit?

[arthurbalduini]

Hello, @dlsso. We are currently working on a feature to cover this behavior, it should be open for review soon. Unfortunately the workaround you proposed will not throw a validation error since it's not covered in the validation cases. The addition of this case for dateRangePickers is included in the scope of the upcoming feature 🙂

[LukasTy]

@dlsso As @arthurbalduini mentioned, there is no built-in behavior for it yet. Regarding the workaround—you should be able to manually trigger the error state, by controlling the error and providing your validation on top of it. 😉 But if there is no rush for it—consider waiting for a built-in solution. 👍

[dlsso]

Thank you both, I appreciate the feedback!