Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bruns6077 opened this issue Feb 15, 2024 · 9 comments
Open
Assignees
Labels
component: DateRangePicker The React component. component: pickers This is the name of the generic UI component, not the React module! customization: logic Logic customizability enhancement This is not a bug, nor a new feature plan: Pro Impact at least one Pro user

Comments

@bruns6077
Copy link

bruns6077 commented Feb 15, 2024

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

@bruns6077 bruns6077 added the status: waiting for maintainer These issues haven't been looked at yet by a maintainer label Feb 15, 2024
@zannager zannager added the component: pickers This is the name of the generic UI component, not the React module! label Feb 15, 2024
@michelengelen
Copy link
Member

@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?

@michelengelen michelengelen added the customization: logic Logic customizability label Feb 16, 2024
@bruns6077
Copy link
Author

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

@LukasTy
Copy link
Member

LukasTy commented Feb 16, 2024

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

@LukasTy LukasTy added plan: Pro Impact at least one Pro user component: DateRangePicker The React component. enhancement This is not a bug, nor a new feature and removed status: waiting for maintainer These issues haven't been looked at yet by a maintainer labels Feb 16, 2024
@flaviendelangle flaviendelangle changed the title [pickers] Enhancing Date Range Selection: Enforcing Disabled Dates and Custom Day Rendering in Date Pickers [pickers] Allow to refuse range that contains at least one disabled date Feb 21, 2024
@flaviendelangle flaviendelangle changed the title [pickers] Allow to refuse range that contains at least one disabled date [pickers] Allow to refuse ranges that contains at least one disabled date Feb 21, 2024
@flaviendelangle
Copy link
Member

flaviendelangle commented Feb 21, 2024

@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

@arthurbalduini arthurbalduini self-assigned this Jun 17, 2024
@LukasTy
Copy link
Member

LukasTy commented Jun 24, 2024

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
Copy link

dlsso commented Jul 19, 2024

@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
Copy link
Member

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
Copy link
Member

LukasTy commented Jul 22, 2024

@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
Copy link

dlsso commented Jul 22, 2024

Thank you both, I appreciate the feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: DateRangePicker The React component. component: pickers This is the name of the generic UI component, not the React module! customization: logic Logic customizability enhancement This is not a bug, nor a new feature plan: Pro Impact at least one Pro user
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants