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
Shorter dates on client print picasso #4820
Shorter dates on client print picasso #4820
Conversation
4dca5d6
to
1430b5e
Compare
"@vue/runtime-dom": "3.4.21", | ||
"@vue/server-renderer": "3.4.21", | ||
"@vue/shared": "3.4.21", | ||
"@vue/test-utils": "2.4.4", |
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.
why did you move @vue/test-utils down?
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.
It was automatically sorted this way when I installed the new package
@@ -54,15 +53,15 @@ export default { | |||
const radius = '2pt' | |||
return keyBy( | |||
this.relevantScheduleEntries.map((scheduleEntry) => { | |||
const start = dayjs.utc(scheduleEntry.start) | |||
const start = this.$date.utc(scheduleEntry.start) |
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.
Was this change necessary for the translations to work?
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.
No, but I stumbled upon it in a global search and found that it's the only place where we use dayjs differently. I thought it would be good to be consistent, if only to make future global searches easier
The recent more complex tests would otherwise result in passing a translation key to dayjs as a date format string. This would result in very hard to understand snapshots. So the easier solution is to just use a real intlify instance initialized with only the common translations.
aa9bc6e
to
63ea382
Compare
When looking at a HeLa-picasso, I noticed that the word "September" may take up a lot of space, and not always look good on a landscape picasso. This change adjusts client print to the same date format on picasso day headers as we already use in nuxt print.
When updating the snapshots, I noticed that the snapshotted dates after this change looked something like
g5/10/2024obam5/10/2024.5amteti0e.5amte05/10/2024ong - g5/13/2024obam5/13/2024.1amteti0e.1amte05/13/2024ong
. This is because in our test setup so far, we mocked $tc as(key) => key
. When callingthis.$date(this.$tc('some.translatable.date.format'))
, the keysome.translatable.date.format
would partially be interpreted by dayjs. To prevent this from making our snapshots unreadable, I switched the tests to use a real intlify (vue-i18n) instance, fed with the common translations which are available (but so far unused) in the client print module.