-
Notifications
You must be signed in to change notification settings - Fork 1
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
fix: improve date parsing for collection items #732
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Datadog ReportBranch report: ✅ 0 Failed, 8 Passed, 1 Skipped, 7.2s Total Time |
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.
suggest keeping ISO format instead of the new dd/mm/yyyy format. please use date-fns instead!
packages/components/src/templates/next/layouts/Collection/Collection.stories.tsx
Outdated
Show resolved
Hide resolved
packages/components/src/templates/next/layouts/Collection/utils.ts
Outdated
Show resolved
Hide resolved
971d95d
to
390ee8e
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.
do you think we should have an equivalent function for dates in studio so that this implicit contract is kept?
"DD MMM YYYY", | ||
"YYYY-MM-DDTHH:mm:ss.SSSZ", | ||
]).format("D MMMM YYYY") | ||
export const getFormattedDate = (dateString?: 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.
we can make use of a branded type here so that we know this is a special "formatted date" string when this function finishes processing
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 usually the result is directly used and not further processed, but added in 2daaaf2 for forward compatibility.
try { | ||
if (isMatch(dateString, "dd/MM/yyyy")) { | ||
return parse(dateString, "dd/MM/yyyy", new Date()) | ||
} | ||
|
||
if (isMatch(dateString, "d MMM yyyy")) { | ||
return parse(dateString, "d MMM yyyy", new Date()) | ||
} | ||
|
||
if (isMatch(dateString, "d MMMM yyyy")) { | ||
return parse(dateString, "d MMMM yyyy", new Date()) | ||
} | ||
|
||
if (isMatch(dateString, "dd MMM yyyy")) { | ||
return parse(dateString, "dd MMM yyyy", new Date()) | ||
} | ||
|
||
if (isMatch(dateString, "dd MMMM yyyy")) { | ||
return parse(dateString, "dd MMMM yyyy", new Date()) | ||
} | ||
|
||
if (isMatch(dateString, "yyyy-MM-dd")) { | ||
return parse(dateString, "yyyy-MM-dd", new Date()) | ||
} | ||
|
||
if (isMatch(dateString, "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'")) { | ||
return parse(dateString, "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", new Date()) | ||
} |
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.
what do we feel about using a reducer pattern here - [formats].reduce(...)
with the starting value as new Date
?
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.
Ah yes, good idea, updated in 2daaaf2.
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.
lgtm. we should shift the try/catch
inside cos that impacts readabiliy and the wideness of the try/catch
makes it difficult to tell exactly what we're catching
leave it to you if we want to refactor the reduce
orders
if (isMatch(dateString, format)) { | ||
return parse(dateString, format, new Date()) | ||
} |
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: we should shift the try/catch
here since this is the only thing that can fail
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.
Done in 715e22c.
"yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", | ||
] | ||
|
||
export const getParsedDate = (dateString: 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.
actually the flow i had in mind was reduce(function, new Date()
then in our reducer function:
if (isMatch(date)) { // parse }
and we can put supported date formats in increasing order of priority, so that the code looks cleaner overall. not a big deal though, just that this was not quite what i had in mind
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.
Hmm I a bit confused, I think that's what I'm doing right now? The reducer function is indeed going by priority (from first to last element) and it starts with undefined
to differentiate between whether the date string has been parsed or not. If parsed then the type is of Date, otherwise it will remain as undefined.
Problem
Some of the dates in collections show up as invalid date because the allowed date format is very specific.
Solution
Breaking Changes
Bug Fixes: