-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
[DateRangeInput] Add allowSingleDayRange prop #861
Conversation
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 we have this util already? DateUtils.areSameDay
return [startDate, (startDate >= endDate) ? null : endDate] as DateRange; | ||
const selectedRange = this.props.allowSingleDayRange | ||
? [startDate, (clearTime(startDate) > clearTime(endDate)) ? null : endDate] | ||
: [startDate, (clearTime(startDate) >= clearTime(endDate)) ? null : endDate]; |
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.
what about DateUtils.areSameDay
? that's what DateRangePicker
uses to implement this prop.
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.
wait but actually... why does this get reimplemented here? can we not rely on DRP's own allowSingleDayRange
prop implementation?
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.
Yeah there's a little duplication between the implementation for the next-selected dates on click and the next focused fields on click (and still more duplication/logic overlap for validation).
But you're right: the basic way to check this is !DateUtils.areSameDay(startDate, endDate) && startDate > endDate
. Will edit.
|
||
// deselect current end date | ||
getDayElement(END_DAY).simulate("click"); | ||
|
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.
such whitespace. i mean whatever, but i like keeping blocks of interaction between asserts together.
055a7a9
to
d869942
Compare
@giladgray ready for re-review |
|
||
// this helper function checks if the provided boundary date *would* overlap the selected | ||
// other boundary date. providing the already-selected start date simply tells us if we're | ||
// currently in an overlapping state. |
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.
nits: should the comment go here, or with the method? also, sentence casing
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 special usage of the helper function, so I think it makes sense to keep the comment only here.
We don't do sentence casing in comments AFAIK, unless it's a prop-description comment.
Addresses #805
Checklist
Changes proposed in this pull request:
allowSingleDayRange
prop toDateRangeInput
Reviewers should focus on
Screenshot