-
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
date: Add types #29789
date: Add types #29789
Conversation
Size Change: +1.08 kB (0%) Total Size: 1.4 MB
ℹ️ View Unchanged
|
2e875d4
to
4d72288
Compare
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 work 👍 I've left some questions and nits but this looks great overall!
* @property {MomentLocaleSpecification['months']} months Locale months. | ||
* @property {MomentLocaleSpecification['monthsShort']} monthsShort Locale months short. | ||
* @property {MomentLocaleSpecification['weekdays']} weekdays Locale weekdays. | ||
* @property {MomentLocaleSpecification['weekdaysShort']} weekdaysShort Locale weekdays short. |
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.
There are a bunch more locale specification properties available. Should we include more as available?
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 only included the ones that are actually used in the settings
object and in the setSettings
function. Were the specific other ones you think we should include for some reason even though they're not 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.
I think that's a good start 👍 The only problem would be if someone uses some of the other ones and gets TS errors. Those could be added incrementally, though - this isn't something that should be blocking 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.
Oh hmm that's interesting. I guess someone could be adding extraneous properties? But then shouldn't they indeed get an error considering those properties aren't supported by the code? Or should we extend this as a Record<string, any>
?
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.
Well, the thing is that they're supported by Moment, so practically they're also supported by the code. The typed ones we're adding here are only the default settings, right?
Anyway, we could make this a Record
, but I believe would be much more precise if we just borrow the rest of the LocaleSpecification
interface.
I'll leave it to you to decide the level of precision you'd like to achieve with this first PR - I'm fine with what we have as a start already 👍
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.
The typed ones we're adding here are only the default settings, right
Nope, if you check out the setSettings
function I only added the properties we actually access off the l10n
object.
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.
Gotcha 👍
Well, I don't see a good reason to add more in that case.
@@ -212,7 +258,7 @@ const formatMap = { | |||
*/ | |||
z( momentDate ) { | |||
// DDD - 1 | |||
return '' + parseInt( momentDate.format( 'DDD' ), 10 ) - 1; | |||
return ( parseInt( momentDate.format( 'DDD' ), 10 ) - 1 ).toString(); |
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.
👍
minutes * MINUTE_IN_SECONDS + | ||
hours * HOUR_IN_SECONDS ) / | ||
86.4 | ||
).toString(), |
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 safe, parseInt()
will implicitly convert to string before parsing to an integer, so it's even better if we do it explicitly.
const parts = offset | ||
.substring( 1 ) | ||
.split( ':' ) | ||
.map( ( n ) => parseInt( n, 10 ) ); |
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.
The explicit conversion looks much better than the one we were implicitly doing with multiplication and addition below 👍
@tyxla Could this one get one last review from you? |
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.
Nothing more to add. Looks great 🚢
Description
Adds/fixes existing types for the
date
package.There are some minor runtime changes but nothing major enough that I thought we should split this into several PRs. Hopefully this isn't too bad to review, happy to walk anyone through my changes though if y'all want it.
Part of #18838
How has this been tested?
Unit tests pass and type check passes.
Types of changes
Non-breaking changes, just adding types 🙂
Checklist: