Allow full day states.#57
Conversation
|
Any input on that? Will it be merged? |
|
This would be very useful for me right now. Is there anything that needs to be added for this PR to be merged? I'd be willing to invest some time. |
| // the other begins; for the block to work, we have to extend the | ||
| // ranges by one day. | ||
| blockedRanges = blockedRanges.map(r => { | ||
| r = r.clone(); r.start.subtract(1, 'day'); r.end.add(1, 'day'); return r; }) |
There was a problem hiding this comment.
I guess it might be more readable to split this up into multiple lines.
There was a problem hiding this comment.
@miracle2k if you could just split these lines up for readability
|
It would be great to take a look at this PR and decide whether to merge it or making further changes. This would be very useful for many cases when the range picker is not used for hotel-related dates selection. |
|
Any update about this PR ? I agree that the current behavior doesn't match every use case... |
|
@miracle2k an accompanying test would be nice to have |
|
I don't have time to work on this at this time, but would be glad if someone could help get it merged. |
Commit copied from PR onefinestay#57 https://github.com/onefinestay/react-daterange-picker/pull/57/commits # Conflicts: # src/DateRangePicker.jsx
6 participants
Currently the date range picker has this behaviour, where the start and end
date of a blocked range is actually selectable, and considered to be a "half"
day (internally called am or pm). I think this is not desirable in many cases,
including ours.
This adds a new property fullDayStates (default false) that can be used to change the
behaviour.
As an implementation note, I found the behaviour of the transparent "default"
state ranges that are being inserted a bit confusing; it means that the
DatePicker assumes that the user provided state ranges are (a) ordered (b) do
not overlap (which is not an obvious assumption) and for this change it means
we have to make an change in the way the default ranges are generated, since
otherwise the CalenderDate object has a hard time telling if it is at a range
boundary or not (see the comment in getDateStates).