-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
minDate and maxDate to block navigation #1311
minDate and maxDate to block navigation #1311
Conversation
@@ -33,6 +35,8 @@ const propTypes = forbidExtraProps({ | |||
}); | |||
|
|||
const defaultProps = { | |||
hasPrev: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
boolean props should default to false, so that absence and falsiness are the same. Can the naming of these be inverted?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed! Let's call this disablePrev
and disableNext
instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point. I've come up with isPrevMonthBlocked
/isNextMonthBlocked
, to try and keep it consistent with isDayBlocked
prop.
enableOutsideDays, | ||
} = this.props; | ||
|
||
const isMinDateVisible = isDayVisible(minDate, visibleMonth, numberOfMonths, enableOutsideDays); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If minDate is falsy, it seems like there’s no point in calling isDayVisible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, it will return false in that case.
Happy to change it to make it more readable. I guess it's a good thing not to rely on the method accounting for that scenario (non-moment date). Make it less "magical"
} = this.props; | ||
|
||
const isMinDateVisible = isDayVisible(minDate, visibleMonth, numberOfMonths, enableOutsideDays); | ||
const isMaxDateVisible = isDayVisible(maxDate, visibleMonth, numberOfMonths, enableOutsideDays); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here
import isBeforeDay from './isBeforeDay'; | ||
import isAfterDay from './isAfterDay'; | ||
|
||
export default function isDayVisible(day, month, numberOfMonths, enableOutsideDays) { | ||
if (!moment.isMoment(day)) return false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good change, even if my above comments are addressed (either this function should throw or return false on a non-moment object)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Followed the same pattern as other utils that do an early return if non-moment object, not sure if it was intended not to have a check but the tests don't break
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm super hype on this idea. Thank you for contributing!
One thing I was thinking about is that I'd love to align this somehow with the concept of the blocked-outside-range
modifier. Specifically, I'd like to eventually replace isOutsideRange
with minDate
and maxDate
in a follow-up breaking change. However, that means that I don't think disabling the month navigation should be intrinsically tied to these props. Maybe we could have:
maxInRangeDate
minInRangeDate
disableMonthNavOnOutsideRange
(it could be less verbose, but that's the general gist of what I am thinking)
src/components/DayPicker.jsx
Outdated
@@ -73,6 +73,8 @@ const propTypes = forbidExtraProps({ | |||
horizontalMonthPadding: nonNegativeInteger, | |||
|
|||
// navigation props | |||
hasPrev: PropTypes.bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's call this disablePrev
and disableNext
to address Jordan's comments.
@@ -33,6 +35,8 @@ const propTypes = forbidExtraProps({ | |||
}); | |||
|
|||
const defaultProps = { | |||
hasPrev: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed! Let's call this disablePrev
and disableNext
instead
@@ -138,8 +147,9 @@ function DayPickerNavigation({ | |||
]), | |||
)} | |||
aria-label={phrases.jumpToPrevMonth} | |||
onClick={onPrevMonthClick} | |||
onClick={hasPrev ? onPrevMonthClick : () => {}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's have this be undefined if it's disabled, so something like hasPrev ? onPrevMonthClick : undefined
instead
onKeyUp={(e) => { | ||
if (!hasPrev) return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here. let's just not define this function if hasPrev is false.
@@ -177,8 +188,9 @@ function DayPickerNavigation({ | |||
]), | |||
)} | |||
aria-label={phrases.jumpToNextMonth} | |||
onClick={onNextMonthClick} | |||
onClick={hasNext ? onNextMonthClick : () => {}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comments apply here about using undefined instead of a thunk
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious: I guess there's an advantage by using undefined instead of a thunk ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Setting it to undefined is akin to not having that prop set at all, which means no unnecessary click handler. Otherwise you're adding a click handlers to things that don't need them, only to call an empty function upon invocation.
onKeyUp={(e) => { | ||
if (!hasNext) return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's not define this when we're disabling the button.
@@ -747,6 +752,23 @@ export default class DayPickerRangeController extends React.Component { | |||
}); | |||
} | |||
|
|||
getNavigationStatus(visibleMonth) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I'm not sure that this name is clear. I'd almost rather have two methods, one that asks if we should disable prev month navigation and one that asks about next month navigation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be kept as one method, as the only difference between them would be the arguments (date, visibleMonth)
. Maybe shouldDisableMonthNavigation
?
@majapw I'm not that familiar with all features of the component but is I noticed that I can see a use case (not sure if it's the one you're mentioning) where I specify that I can only select a Can you expand a bit on your idea ? I can try to have a look (perhaps not for this PR) Also, I think I addresed all the comments (cc @ljharb) |
@majapw any other thoughts on this ? |
Any update on this? This seems like a good feature to have, if there are no blockers can it please be merged? |
Anything missing ? cc @majapw @ljharb @backwardok |
Please do rebase it, instead of clicking "update branch" which produces a merge commit. |
Anything missing ? cc @majapw @ljharb @backwardok |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay! I'm good after the changes I suggested but I defer stamping to @majapw since she's more familiar with the codebase than I am
@majapw do you have time to review this? Really looking forward to seeing this to be released. Thanks!! |
I see these |
Seems to be as easy as adding |
@pedroabreu thanks for the quick reply. When I try adding them to |
Sorry, I mean add them as props to the component and pass it down to the
controller.
…On Tue, Mar 12, 2019 at 23:33 Andrew Vivash ***@***.***> wrote:
@pedroabreu <https://github.com/pedroabreu> thanks for the quick reply.
When I try adding them to DateRangePicker, I get an error, as it doesn't
recognize the props
[image: image]
<https://user-images.githubusercontent.com/1179291/54243137-7ce31580-44e4-11e9-85cb-fa045058f2fe.png>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1311 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABI7iEZrWIrTaf6pqFA4drpaMZUVJQNpks5vWDk1gaJpZM4V9RGc>
.
|
@pedroabreu sorry, I think I'm misunderstanding you. Are you suggesting a hierarchy like this?:
|
I believe they are suggesting making a change in this package itself to pass those props down. |
Sorry, it's what @ljharb mentioned. These props are not part of the I'll open a PR for this, should be pretty straightforward (famous last words) |
Thanks @ljharb / @pedroabreu. That's great! I'll be sure to look out for a PR |
PR opened: #1582 |
Thanks for getting this addressed so quickly! |
PR to improve upon the stories created by this PR: #1598 |
Does this not work for the SingleDatePicker? Edit: Nvm, addressed in later PR: #1927 |
Adds feature to block month navigation depending on a minDate/maxDate prop.
Resolves #339