-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Datepicker: Allow null value for currentDate on mounting #12963
Datepicker: Allow null value for currentDate on mounting #12963
Conversation
cb3507b
to
6535d09
Compare
96eab9a
to
477b060
Compare
Wouldn't this be considered a breaking change for someone who might have relied on the current behavior? Is a middle-ground option that we allow for an explicit |
Great feedback here, thank you @aduth ! I've added a method |
@@ -25,7 +25,7 @@ class DatePicker extends Component { | |||
onChangeMoment( newDate ) { | |||
const { currentDate, onChange } = this.props; | |||
|
|||
const momentDate = currentDate ? moment( currentDate ) : moment(); | |||
const momentDate = this.getMomentDate( currentDate ); | |||
const momentTime = { | |||
hours: momentDate.hours(), |
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.
getMomentDate
can return null
, at which point this would throw an error.
It would be good to document any function we introduce, as it may make this sort of thing easier to catch, when recognizing that the return value of the function is nullable.
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.
Unit tests, as well, would be good to capture this sort of issue and the expected behavior.
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.
Eesh, good call. I've gone back to the original implementation here and included a comment about to explain why moment()
is used if currentDate
is undefined or null.
Unit tests added. Thanks
a81e205
to
79ff4a3
Compare
*/ | ||
import DatePicker from '../date'; | ||
|
||
describe( 'DatePicker', () => { |
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 glad to see tests, but for what it's worth these tests as written would not have caught the error described in my previous review, since there is zero coverage for onChangeMoment
.
Thanks for the edits to the jsDoc @aduth. I added testing to |
eb11780
to
08578e8
Compare
08578e8
to
2e40cf6
Compare
const onChangeSpy = jest.fn(); | ||
const wrapper = shallow( <DatePicker onChange={ onChangeSpy } /> ); | ||
const newDate = moment( '1986-10-18T11:00:00' ); | ||
const current = moment(); |
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 worries me a bit; I feel like it will be prone to test fragility, where the time required to execute the test is such that moment()
called here will produce a different time than moment()
called within the implementation of onChangeMoment
. Usually this should take a mere fraction of a second, but I've witnessed in the past where it's enough time to tick into the next second and cause an uenxpected test failure.
I think our options would be:
- Find a way to provide or otherwise control the current time as referenced within
onChangeMoment
- Mock
moment
to have full control over what it returns† - Provide some flexibility in the assertion (i.e. within a +/- allowable timeframe)
- Don't test it
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.
Lets go with Provide some flexibility in the assertion (i.e. within a +/- allowable timeframe)
for $1000 please, Alex.
I figured comparison on basis of seconds was enough to overcome differences in execution time, but in an effort to prevent future headaches, a change is a good idea.
I changed the tests to save the argument passed to onChange for later comparison using moment's isSame
function. Then I compare with a granularity of minute
, which would preclude all but the rarest of circumstances where a pause in execution time ticks into the next second AND minute.
Hi @aduth, would you have a moment to give this another look? I changed the tests to save the argument passed to onChange for later comparison using moment's Many thanks! |
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.
When it comes to intermittent test failures, I'd prefer "impossible" over "rare", but I'll take what I can get.
Thanks for your patience 👍
Yikes, thanks for the heads up. I'll look into this to evaluate other solutions |
* Datepicker: Allow null value for currentDate on mounting * flexible assertion, FTW
* Datepicker: Allow null value for currentDate on mounting * flexible assertion, FTW
Description
When a
null
value is passed to<DatePicker >
, don't set the date to current date. Instead, allow the value to remain null such that no selection is visible on the calendar.undefined
values forcurrentDate
behave as they did previously, which is to fall back to the today's date.Testing
currentDate
to todays date by default does not exist by pulling down the branch and seeing that nothing breaks.null
value for thecurrentDate
prop on<DatePicker >
to ensure nothing breaks and no date is selected.currentDate
prop and see the date picker default to today's date.gutenberg/packages/components/src/date-time/index.js
Lines 48 to 51 in 0c734e1
Screenshots
Types of changes
New feature: Allow null value of date selection to persist such that no date is selected on the calendar.
Checklist: