STCOM-1094 Replace momentJS with dayJS #2192
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
JohnC-80
changed the title
ncovercash
reviewed
Jan 4, 2024
…components into dayjs-refresh
This was referenced Jan 5, 2024
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For many instances,
dayJSis a drop-in replacement formoment. There are a handful of differences when dealing with time/timezones.Most notable was a
dayjsbug for theutcplugin when an array of possible formats are provided - the resulting datetime bakes in an offset. This is due to an issue that's surfaced in a dayJS PR - but this shouldn't affect most FOLIO usage at the app level, as that level tends to deal with dates or times exclusinvely in the ISO8601 format if not just a plain string. Further, it was easy enough to circumvent with a small utility method to check the array of intended formats individually.Additionally was a local implementation of a dayjs range - simply just an array of dayjs objects vs the npm import
moment-range. There is a dayJS issue for this with some ideas included.Importing is also a bit different with Dayjs - to supplant their bullet-point of '2kb' size, they require you to import and
extenddayJS through individual plugins that cover anything from advanced formatting to handling UTC time.Dayjs i18l is pretty straightforward, with their locales broken out into separate modules and load-able via dynamic import - This PR includes some utilities - 1 hook, 1 component to handle this feat (the component uses the hook and it's for non-functional components that can't just use the hook.) Some slight adjustment had to be done in order to support "non-primary/non-native" locale/region combinations ('en-SE') and get weekday alignment on the Calendar working correctly.
This probably represents the biggest lift we'd have to do for removing moment. More datetime library code is here than should be employed at the ui-module level... (aside from ui-calendar, perhaps.)