-
-
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
added reopenPickerOnClearDates prop #75
Conversation
Naming the prop in this way makes it a breaking change - it'd be preferred to find a way to name the (default false) prop so that the reopen behavior is the default. |
@ljharb okay will do the same |
@ljharb PR updated please check |
@@ -223,8 +224,11 @@ export default class DateRangePicker extends React.Component { | |||
} | |||
|
|||
clearDates() { | |||
this.props.onDatesChange({ startDate: null, endDate: null }); | |||
this.props.onFocusChange(START_DATE); | |||
const {onDatesChange, reopenPickerOnClear, onFocusChange} = this.props; |
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.
curly braces need spaces inside them
@ljharb made all the changes recommended by you please check |
Thanks, LGTM! It'd be great to also add an example for it in the storybook. |
@ljharb there is already a case for clear button would modify the same right according to the new feature added. One more thing is there a channel or IRC channel where the developers of this repo can be contacted for doubts in the code? |
added the example in storybook also |
@@ -43,6 +43,7 @@ const defaultProps = { | |||
numberOfMonths: 2, | |||
showClearDates: false, | |||
disabled: false, | |||
hidePickerOnClear: 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.
If you click the clear button now when the datepicker is open, I don't think this will actually hide the picker so this prop name is a misnomer. Something like dontReopenPickerOnClear
maybe makes more sense... or even in this case, it might be worth it to have the semver breaking change of reopenPickerOnClear
. What do you think @ljharb?
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 we're comfortable with a breaking change, then sure - that might be better.
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 that would be fine. We can couple the release with #53 for 3.0.0. I think, semantically, reopenPickerOnClearDates
seems like a better name
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.
Thanks for the example. In addition to my comment about the naming, we'll definitely need to add a bit to the We don't have a channel for discussing this code yet, but opening up an issue is probs the easiest way to get in touch. |
@majapw yaa i saw your comment, whatever name you guys finalize wont be a major change so once it finalized will change the name and add the corresponding readme regarding it. This would be my first commit to the library and would like to solve other open issues as well. I asked for some channel so as to ficilitate some doubts that i might have in the code :) |
Hi @agupta93! It looks like this is breaking the Can you also rebase locally and push it up instead of hitting the update branch button? That would help immensely in keeping our tree clean. |
@majapw corrected the build error and added the test for the same please check :) |
@@ -154,17 +154,32 @@ describe('DateRangePicker', () => { | |||
}); | |||
|
|||
describe('#clearDates', () => { | |||
describe('props.reopenPickerOnClearDates', () => { |
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.
So probably the structure of these tests should look something like:
describe('#clearDates', () => {
describe('props.reopenPickerOnClearDates is truthy', () => {
describe('props.onFocusChange', () => {
it('is called once', () => {
...
});
it('is called with arg START_DATE', () => {
...
});
});
describe('props.reopenPickerOnClearDates is falsey', () => {
describe('props.onFocusChange is not called', () => {
...
});
});
});
Some of these tests are duplicates right now.
Right now the travis build is failing on some linting rules! You should address those and also run |
@majapw all changes done as asked hope everything looks fine now ✌️ |
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.
LGTM. Is there any way you can squash your five commits into one single commit? I'll merge it in after that.
@majapw commits squashed !! |
@agupta93 ! Thank you! |
This PR is in response to the issue #68 . As requested a prop
reopenPickerOnClearDates
has been added which governs whether the picker will be shown when clear is clicked.By default the value is set to false.