-
-
Notifications
You must be signed in to change notification settings - Fork 29
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
feat(common)!: migrate from moment
to moment-tiny
#1456
Conversation
- in theory the `module` defined in the `package.json` is now linked to the ESM build as per this recent Moment [commit](moment/moment@87994b7)
- so I created yet another repo, it is very similar to `moment-mini` except that it includes both CJS and ESM builds (which actually both come from the Moment project), however `moment-mini` only includes the CJS build.
Run & review this pull request in StackBlitz Codeflow. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## next #1456 +/- ##
=======================================
- Coverage 99.8% 99.7% -0.0%
=======================================
Files 197 197
Lines 21653 21652 -1
Branches 7066 7069 +3
=======================================
- Hits 21589 21586 -3
- Misses 58 60 +2
Partials 6 6 ☔ View full report in Codecov by Sentry. |
const output = executeFilterConditionTest(options, getFilterParsedDates(searchTerms, FieldType.dateEuroShort)); | ||
expect(output).toBe(true); | ||
}); | ||
|
||
it('should return False when input value equals the search terms min inclusive value and operator is set to "RangeExclusive"', () => { | ||
const searchTerms = ['01/12/93..31/12/93']; | ||
const options = { dataKey: '', operator: 'RangeExclusive', cellValue: '01/12/93', fieldType: FieldType.dateEuroShort, searchTerms } as FilterConditionOption; | ||
const searchTerms = ['1/12/93..31/12/93']; |
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.
is there a different behavior now with the date parsing?
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.
for unknown reason the newer version of moment doesn't accept zero padding anymore and in some ways it makes sense though, If we look at their Format docs, it does show only 1 digit when using D
or M
. I could use DD
or MM
but I'm not sure if that would work and what I'm almost certain is that would probably fail in strict mode when zero padding is missing... I can give it another try tonight though
I guess that what you're saying is that because of this, I might have to wait until next major and advertise the possible strictness in next major, is that it?
ok so I went through all their recent PRs and found this commit introduced in v2.30.0 so it seems that it doesn't accept zero padding in strict mode only. I think I use strict mode when sorting and filtering
Sorting
export function compareDates(value1: any, value2: any, sortDirection: number, format: string | moment_.MomentBuiltinFormat, strict?: boolean) { | |
let diff = 0; | |
if (value1 === value2) { | |
diff = 0; | |
} else { | |
// use moment to validate the date | |
let date1: moment_.Moment | Date = moment(value1, format, strict); | |
let date2: moment_.Moment | Date = moment(value2, format, strict); |
Filtering
slickgrid-universal/packages/common/src/filter-conditions/dateFilterCondition.ts
Lines 11 to 20 in 5ab671b
export function executeDateFilterCondition(options: FilterConditionOption, parsedSearchDates: any[]): boolean { | |
const filterSearchType = options && (options.filterSearchType || options.fieldType) || FieldType.dateIso; | |
const FORMAT = mapMomentDateFormatWithFieldType(filterSearchType); | |
const [searchDate1, searchDate2] = parsedSearchDates; | |
// cell value in moment format | |
const dateCell = moment(options.cellValue, FORMAT, true); | |
// return when cell value is not a valid date | |
if ((!searchDate1 && !searchDate2) || !dateCell.isValid()) { |
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.
@zewa666 I gave it a try and it is as I thought, when having a date like 01/01/92
and M/D/YY
will not pass in strict mode. I think I should keep using strict mode in my lib nonetheless... So it really looks like MomentJS introduced a breaking change without even knowing and for that reason, I guess I have no choice but to postpone it for the next major release in 2 months and mention this new strictness in the migration
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.
@zewa666 alright, so what I found is that to go around the more strictness parsing problem with the new MomentJS version, what we can do is to provide multiple formats via an array. So what I've done is to add 2 formats for all the date formats that are considered as short. For example with Field.dateUsShort
, I'm now passing ['MM/DD/YY', 'M/D/YY']
so that the user can still pass dates with/without zero padding. However there are 3 things to note
- I can only use 1 output format and so I will always prefer the format with zero padding
MM/DD/YY
- parsing with multiple formats is slower than passing a single format and the array order matters, so zero padding will be quicker
- I use strict mode when filtering & sorting, another idea would be to loosen the parsing and not use strict mode but non-strict mode is often too loose and I prefer strict mode
More info can be found in this Moment doc:
https://momentjscom.readthedocs.io/en/stable/moment/01-parsing/04-string-formats/
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.
awesome feature. just need something like that for the paste handling
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.
wow you're not sleeping, I thought you would reply in a day or two 😋
awesome feature. just need something like that for the paste handling
do you mean for another feature like the copy handler or did you mean something else? Should I go ahead with the merge then? what is your thought on the subject? I guess I'll be ready for a beta version by next week :)
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.
kids just woke me up ;)
yeah we've just experienced during the POC that handling date pastes might be tricky as people usually have excel files and stuff whatever they found right into the grid. So having the combo of a couple of supported formats + a locale is a great option.
I think this is definitely good for merge.
going to have another week to focus on the grid in 2w so looking forward to incorporate the new releases and fixes 🎉
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 I wish that I could have switched to date-fns but it always seems that MomentJS is still the best and no other lib have all the bells and whistles of Moment.
So I might have a beta by next week but it's still earlier than Angular 18 (which is scheduled for around May 20), however I will still make it the new minimum version requirement. I'm quite happy with the switch to pure CSS SVG, the Dark Mode is looking so so much better 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.
dont look at me, still using moment and numeral in most projects bc it just works and the size overhead is ignorable in enterprise internal only apps. 😅
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 totally agree with all of that
hah thats a nice coincidence. we just installed moment yesterday for the date parsing of our dynamic column formatstrings and adding cjs to the new vite build felt so wrong 😅 I'm gonna give it a try as well |
Yeah so as I mentioned in the other discussion, as per this Moment commit, they transpile to ESM but if you look at their |
moment
to moment-tiny
moment
to moment-tiny
- the latest version of MomentJS is not as loose as previous version (especially since we use strict mode when filtering & sorting), however what we can do is provide multiple formats to accept with/without zero padding so that both ("1/2/98" and "01/02/98" would work). - Note however that as mentioned in MomentJS docs > Note: Parsing multiple formats is considerably slower than parsing a single format. If you can avoid it, it is much faster to parse a single format. - so we'll do multiple formats only for formats that are considered shorts
@zewa666 have you had a chance to try |
@zewa666 yeah ok but that's probably just because I did add an But anyway, does this new package help at all with Vite? is it better than using Moment (or moment-mini)? slickgrid-universal/test/jest-global-mocks.ts Lines 41 to 45 in 3649484
|
oh ok I see. I'll give it a try with angular and see how it goes |
moment-mini
except that it includes both CJS and ESM builds (which actually both come from the Moment project itself), howevermoment-mini
package only references the CJS build even they build both CJS & ESM nonetheless (more info can be found on the moment-tiny repo)Note
The newest version of MomentJS introduced a breaking change via this PR even if they released it under patch, it really is a breaking change (more strict on 1-2 digits). I think what I could do to ease the pain would be to add a new
strictDateParse
(defaulting totrue
) so that user could avoid the breaking change. The reason not to use non-strict is mostly it's way too loose by default which is why I prefer strict by default but providing a date of01/01/23
withD/M/YY
should still be accepted and it was prior to that referenced commit. The strict mode is mostly used in the Date Sorting and FilteringTODOs
['M/D/YY', 'MM/DD'YY']
(however note that this could potentially impact perf unless 1st format is the correct one)