-
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
[datetime] remove moment dependency #2117
Conversation
RadioGroup allows number selectedValue (because Radio value does)
refactor DateRangeInput to use formatter instead of momentPreview: documentation | landing | table |
What's the total bundle size reduction? |
@adidahiya thoughts on borrowing r-d-p's
update: i did this. it's nice. |
@@ -49,7 +49,7 @@ export interface IRadioGroupProps extends IProps { | |||
options?: IOptionProps[]; | |||
|
|||
/** Value of the selected radio. The child with this value will be `:checked`. */ | |||
selectedValue?: string; | |||
selectedValue?: string | number; |
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.
remove unrelated 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.
oh but it is related, or i wouldn't have pushed it. for FormatSelect
, which uses the index in an array. Radio
supports number values, so RadioGroup
should do.
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.
separate PR please
dateToString: date => date.toLocaleString(), | ||
placeholder: "enter date", | ||
stringToDate: str => new Date(Date.parse(str)), | ||
}; |
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.
big problems with this formatter. Date.parse(str)
uses UTC timezone for "YYYY-MM-DD" strings, so some dates come out a day earlier than expected. should I just use a moment formatter in these tests?
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.
new Date("2/1/2015")
> "Sun Feb 01 2015 00:00:00 GMT-0800 (PST)"
new Date("2015-02-01")
> "Sat Jan 31 2015 16:00:00 GMT-0800 (PST)"
…he component level; used in DateInput + DateRangeInput
@themadcreator there's no immediate change in bundle size as this change makes |
quick-fix DRI (still needs attention)Preview: documentation | landing | table |
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.
general direction lgtm. I think we should also apply this kind of change to the timezonepicker and require new timezone-related props for that component. then we can pull it back into @blueprintjs/datetime
and remove the new package we made.
valueString: null, | ||
}; | ||
} | ||
public state: IDateInputState = { |
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.
are you sure it's ok to move this to the static member? why did we have it in the constructor before?
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 am quite sure. typescript always inline state init in the constructor that it generates (before all the other =>
bound methods), so you can actually safely use this.props
in public state
initialization.
packages/datetime/src/dateInput.tsx
Outdated
if (this.props.timePrecision == null) { | ||
return false; | ||
} | ||
// TODO: getTime()? |
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.
- resolve this TODO in this PR
* Return `false` if the string is an invalid date. | ||
* Return `null` to represent the absence of a date. | ||
*/ | ||
parseDate(str: string, format?: string, locale?: string): Date | false | null; |
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.
not a huge blocker, but curious about this API decision: why would a consumer expect format
in this function? if they're providing format
as a prop, they already know the format they're interested in. in the usage of props.parseDate()
it seems like you're passing props.format
directly anyway.
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.
prior art: http://react-day-picker.js.org/api/DayPickerInput#formatDate.
this is the only place the format
prop gets used, so we could drop it from the API and push it to the user. but the nice thing about this usage is that only one set of moment utils for format/parseDate
could be used for all formats.
packages/datetime/test/isotest.js
Outdated
@@ -8,9 +8,18 @@ const React = require("react"); | |||
const DateTime = require("../lib/cjs"); | |||
|
|||
describe("DateTime isomorphic rendering", () => { | |||
const format = { |
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.
nit: formatProps
I didn't look at the logic very closely but I assume it's covered by the extensive test suite |
dc4f746
to
e56625f
Compare
fix most DRI testsPreview: documentation | landing | table |
fix all the DRI tests!Preview: documentation | landing | table |
packages/datetime/src/dateFormat.tsx
Outdated
/** | ||
* Date format string, passed to `formatDate` and `parseDate`. | ||
*/ | ||
format?: 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.
@adidahiya what's your take on this prop? worth keeping?
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.
prefer to keep it simple and add it later if it's desired
@adidahiya not sure what you mean with format screenshot, works for me. i just removed the (def broken) "from now" option. |
remove format prop, add formatting testsPreview: documentation | landing | table |
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.
nice docs
we should probably still add a |
add docs section about "Date formatting"Preview: documentation | landing | table |
add imports to docsPreview: documentation | landing | table |
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.
Exciting stuff!
Fixes #1930
Checklist
DateInput
testsDateRangeInput
teststop-levelformat.placeholder
orplaceholder
prop, etc.can I remove any component state fields?if it ain't brokeformatDate()
at render timeChanges proposed in this pull request:
IDateFormatProps
interface extended byDateInput
andDateRangeInput
formatDate
andparseDate
callbacksformat
prop is now just an optional string that is passed to callbacks aboveplaceholder
prop is now on the component itself (neeformat.placeholder
)moment
dependency from datetime packageIDateFormatter
instead of momentReviewers should focus on: