-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Select time feature #839
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
Select time feature #839
Conversation
Codecov Report
@@ Coverage Diff @@
## master #839 +/- ##
==========================================
- Coverage 85.84% 78.77% -7.08%
==========================================
Files 12 13 +1
Lines 643 716 +73
Branches 128 141 +13
==========================================
+ Hits 552 564 +12
- Misses 6 61 +55
- Partials 85 91 +6
Continue to review full report at Codecov.
|
Will work on tests at the weekend. Will creating tests be all thats needed to fix the codecov errors? |
@shadrech Thanks, yes. Codecov only complains about the fact that the current test coverage of this PR is below the target of 75%. Currently the overall coverage floats around 95% for the complete project. |
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.
Based on the recent comment. Please add tests, to make sure all new functionality works as expected.
docs/datepicker.md
Outdated
@@ -313,3 +313,30 @@ type: `string` | |||
type: `bool` | |||
defaultValue: `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.
You can remove this submissions. This will be autogenerated when releasing a new version.
server.js
Outdated
@@ -22,11 +22,11 @@ app.use(require('webpack-hot-middleware')(compiler)) | |||
|
|||
app.use(express.static('docs-site')) | |||
|
|||
app.listen(8080, 'localhost', function (err) { | |||
app.listen(9000, 'localhost', function (err) { |
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.
Do we need this change?
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 forgot to change that back. That port was occupied with a different process when I was developing the datepicker. That change isn't necessary at all
src/datepicker.jsx
Outdated
} | ||
|
||
static get defaultProps () { | ||
return { | ||
dateFormat: 'L', | ||
dateFormat: 'LLL', |
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.
Why's this changed?
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.
"LLL" is more verbose. It displays the time as well. Maybe I should set a if statement if this.props.showTimeSelect is instantiated before changing the format to display time as well
Any progress on this issue? |
My bad. Been really busy at work. Will work on tests this weekend hopefully 🤞🏾 |
…e in timezone_date.tsx
…teFormat must be changed to 'LLL' for time to be displayed
…er ref with setState
89bb96e
to
fe0a5b8
Compare
@martijnrusschen Sorry for hiatus. Added tests but codecov still not happy. Please advise on best way forward? What am I missing here? |
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.
Looks cool! Few comments, I'll let some others review this as well since this is a pretty major addition to the component.
Also, perhaps it would be nice to add something to the Readme about this as well.
@@ -84,6 +84,8 @@ | |||
border-top-right-radius: 0.3rem; |
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.
Can you please exclude changes to this file from the PR? This will be automatically updated when I'm going to run a new release.
@@ -1116,7 +1116,7 @@ | |||
|
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.
Can you please exclude changes to this file from the PR? This will be automatically updated when I'm going to run a new release.
@@ -68,4 +68,4 @@ General datepicker component. | |||
|`value`|`string`||| |
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.
Can you please exclude changes to this file from the PR? This will be automatically updated when I'm going to run a new release.
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 pretty sure I didn't edit these files. They must have been edited when running yarn start
and editing files in src/ directory
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.
@shadrech Yes, they're build outputs.
@martijnrusschen Is there a way we could improve the release process so everyone doesn't need to manually avoid committing these sorts of changes?
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.
@aij Add files ending in .js/.md/.css in directories docs/ & docs-site/ to .gitignore? Since files are auto generated
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.
Problem is that we need the .js and .css files in the gh-pages branch for the docs. It seems pretty hard to ignore something in one branch but have it checked in into the other branch. I read something about it here: https://stackoverflow.com/questions/1836742/using-git-how-do-i-ignore-a-file-in-one-branch-but-have-it-committed-in-another but haven't found the silver bullet yet. Ideas are welcome!
We can't ignore the .md files since those are served in the docs folder in the master branch.
Yh I can add this to README. I had just included examples of how to use the new feature in docs-site/src/examples (exclude_time_period.jsx, exclude_times.jsx, show_time.jsx). But yh I will add some info in README |
What of the tests? @martijnrusschen |
Not sure why codecov isn't liking them. Need to look into that, but for now this seems fine. @aij Any thougths on this PR? |
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 great work.
src/calendar.jsx
Outdated
@@ -264,7 +281,7 @@ export default class Calendar extends React.Component { | |||
var monthDate = this.state.date.clone().add(i, 'M') | |||
var monthKey = `month-${i}` | |||
monthList.push( | |||
<div key={monthKey} className="react-datepicker__month-container"> | |||
<div key={monthKey} ref="monthContainer" className="react-datepicker__month-container"> |
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.
ref="string"
is deprecated in newer React. The new equivalent is ref={r => this.refs.monthContainer = r}
instead, though most people seem to be taking it a step further by avoiding this.refs
entirely, though I'm not sure there's any basis for the later beyond a prominent example.
|
||
export function isTimeInDisabledRange (time, { minTime, maxTime }) { | ||
if (!minTime || !maxTime) { | ||
throw new Error('Both minTime and maxTime props required') |
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.
Why should both be required? For dates we allow upper and lower bounds to be specified independently.
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.
Only applicable if user decides to have a time range. Both values required to create time window. Since time loops at 24 (24 hr clock), setting a lower bound with no upper bound for example won't create a finite window (not good at explaining, hopefully that makes sense)
src/datepicker.jsx
Outdated
@@ -270,6 +277,20 @@ export default class DatePicker extends React.Component { | |||
} | |||
} | |||
|
|||
handleTimeChange = (time) => { | |||
const selected = (this.props.selected) ? this.props.selected : 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.
We don't always default to the current date, and it is not always valid. See calcInitialState()
/ setOpen()
.
src/tether_component.jsx
Outdated
import React from 'react' | ||
import PropTypes from 'prop-types' | ||
import ReactDOM from 'react-dom' | ||
import Tether from 'tether' |
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 looks like the file that was deleted with the conversion to Popper. Was it accidentally reverted somehow?
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 seems an artifact of recent changes. We don't use Tether anymore.
src/time.jsx
Outdated
static propTypes = { | ||
intervals: PropTypes.number, | ||
selected: PropTypes.object, | ||
onTimeChange: PropTypes.func, |
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 have a slight preference for standard prop names (eg onChange
) if we expect this component to be used directly, so users don't need to wrap the component in another component that does little more than renaming props.
selected={this.state.startDate} | ||
onChange={this.handleChange} | ||
showTimeSelect | ||
excludeTimes={[moment().hours(17).minutes(0), moment().hours(18).minutes(30), moment().hours(19).minutes(30), moment().hours(17).minutes(30)]} |
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.
Making this a function/predicate instead of an array might be more flexible, especially if whole time ranges need to be excluded, or if the exclusions need to depend on the date. (Eg, if it is based on available appointment times from a DB, or varies with DST.)
If we expect a fixed/predefined list to be much more common this could be easier to use though. Thoughts?
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 find an array to be more simpler. I imagine a scenario where an api call returns a json array of moment.toISOString strings, and all client has to do is convert these to moment() objects and plug the array into excludeTimes. Even maybe extend excludeTime that first a check is made to see if objects received are strings, and automatically convert to moment() objects. That way client can just pass the json array directly to excludeTimes via a simple JSON.parse?
.react-datepicker__time-container .react-datepicker__time { | ||
position: relative; | ||
background: white; } | ||
.react-datepicker__time-container .react-datepicker__time .react-datepicker__time-box { |
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.
Indentation here and below.
Also seems like a lot of special 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.
Auto generated file, should be removed from this PR.
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.
Yh most of it removed. Main function of special casing was for sizing the time component. Now thats done by calculating the month container height via clientHeight (passed via refs)
@@ -68,4 +68,4 @@ General datepicker component. | |||
|`value`|`string`||| |
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.
@shadrech Yes, they're build outputs.
@martijnrusschen Is there a way we could improve the release process so everyone doesn't need to manually avoid committing these sorts of changes?
docs-site/src/example_components.jsx
Outdated
@@ -193,8 +195,16 @@ export default class exampleComponents extends React.Component { | |||
component: <RawChange/> | |||
}, | |||
{ | |||
title: 'Don\'t hide calendar on date selection', | |||
component: <DontCloseOnSelect/> |
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.
Why was this example removed?
maxTime={moment().hours(18).minutes(0)} /> | ||
) | ||
var times = datePicker.find('li.react-datepicker__time-list-item') | ||
expect(times).to.exist |
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.
Wouldn't this test pass even if minTime and maxTime are ignored?
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.
Lol yh my bad. At first I wanted to test the number of .react-datepicker__time-list-item they'll be; there should be 3 with configuration above. I tried testing with expect(times).to.have.length(3) but kept getting a fail as length always comes back as 0. Any ideas what I'm missing here? Maybe theres another test I can do that'll achieve desired result
Will work on requests at the weekend |
- Removed excessive special casing in scss - Reinstated DontCloseOnSelect - refactored onTimeChange prop name to onChange on Time.tsx - Moved time examples to top of example_components
src/tether_component.jsx
Outdated
@@ -0,0 +1,149 @@ | |||
import React from 'react' |
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.
Please remove the entire file. This isn't used.
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.
👍
Overall looking pretty cool. I'm looking forward to using this! |
Thanks @dola - that was exactly the case for me. I was wondering why adding showTimeSelect to the props did not show up anything when I tested react-datepicker for the first time using 0.54.0. |
PS: The just released 0.55.0 now behaves as expected. Thx! |
Sorry for the confusion, forgot to release this earlier. |
Feature allows users to select a time along with the date. So moment object returned will have specific time
Also includes time filtering with minTime, maxTime and excludeTimes