🕰️ NEW: formatDate

[jycouet]

DO NOT MERGE

Link to: #136

• add changeset (breaking rmv dateDisplay)
• update dateDisplay Doc
  • all relevant things move to format
  • doc: component/dateDisplay to remove (use https://svelte-ux.techniq.dev/docs/components/dateDisplay/) to compare)
  • remove dateDisplay.ts
• update doc to explain format with date

[changeset-bot]

🦋 Changeset detected

Latest commit: acba2a9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte-ux	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
svelte-ux	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 3, 2024 4:28am

[cloudflare-pages]

Deploying with    Cloudflare Pages

Latest commit:	acba2a9
Status:	✅  Deploy successful!
Preview URL:	https://f77463d0.svelte-ux.pages.dev
Branch Preview URL:	https://feat-formatdate.svelte-ux.pages.dev

View logs

[jycouet]

Check out: https://svelte-ux-git-feat-formatdate-techniq.vercel.app/docs/utils/format#playground

[techniq]

Reading #150 and with my current progress, I think that we have to do some choices now :).

For yesterday, 3 days ago, ... this is working well: https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/Intl/RelativeTimeFormat

For date format, ... this is working well: https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat

I started to add a dico, for things that I can't find in intl in a robust way. https://github.com/techniq/svelte-ux/blob/feat/formatDate/packages/svelte-ux/src/lib/utils/date.ts#L97-L105

I think that we will not get rid of date-fns as there are so many good utilities and intl is only about formatting. But, I think that formatting should be done in 1 single way either intl either date-fns, but not both (my current state!)

intl

• It's cool as it's native js support (less to ship in the browser)
• It's cool as it's similar to number that we did before
• It's cool, with 1 string, it's supports so many locales!
• It's not cool as it will be a breaking change for the lib (https://svelte-ux.techniq.dev/docs/components/DateField format will have to be done another way)

date-fns for formatting

• people will be forced to add locales of date-fns
• keeping the way it's done
• less work as it's spread in a lot of places
• convenient for DateField format

I really like the idea of using Intl for all the reasons you mentioned, especially not having to manage/download locales (i.e. date-fns/locale) and the simplicity/consistency. With that said, when I took a look at the PR preview playground, I was initial surprised by the DateField format until I realized that what one of the things you mentioned :).

I also think date-fns provides a lot of additional utility beyond formatting so I'm good with keeping it.

For DateField format default, I wonder if we just keep our own locale/format lookup for this use case.

const defaultFormat = {
  en: 'MM/dd/yyyy',
  fr: 'dd/MM/yyyy',
  ...
}

if we overlook one, we could have it just default to 'MM/dd/yyyy' and if a user complains, we'll know which one we missed :).

We could also take a date like 2023-11-21, format it using toLocaleDateString(locale), then parse where the values ended up, but this might be overkill.

I think the simple map might be the best, as for a default, just getting MDY or DMY or YMD right is good enough. I think always using / as a divider is probably fine too, although I know some locales (or even personal preference) might want to use - or ..

Looking at https://en.wikipedia.org/wiki/Date_format_by_country and https://docs.oracle.com/cd/E19455-01/806-0169/overview-7/index.html, I think we could build up this list fairly easily. Maybe even make it a case statement to simplify the impl (including handling the fallback default).

Lastly, I think we should expose this format on settings() for when a dev/user wants to override the format.

How does that sound? We can try to sync up in a few days and chat about it further if you want too.

[jycouet]

Oups, I just read your message after spending my all afternoon on it 🤣🤞
But, I think we are thinking the same way, hahaha

Check out the update ✅

I love all tests, I'm ssssoooo confident moving things around. And if something is not tracked, it's easy to add it 👍
I tried to clean as much as possible.

I think that I would like to remove dateDisplay! to really cut format from date-fns, but it might break some people code... So I don't know....

I'll do a break now to party a bit 🎉
Speak to you soon

---

FYI, love it:

[techniq]

Happy New Year (not quite here yet)! You've been busy 😅.

I love the idea of removing dateDisplay / consolidating into a single date format function for all use cases (or requiring dateFns format() directly when needed). I know there is a little usage of dateDisplay within LayerChart. There was even a commit that switched from dateFns's format() to dateDisplay(..., { format: ... }) to better handle null so it's not a 100% drop in if we require dateFns for this kind of formatting, but I'm not against it. If you're planning to support custom format strings in formatDate() that would be awesome too (it could still use dateFns, but then I guess we're back with dealing with locales in this case). We might just need to support more PeriodTypes for example time-only (h:mm:ss). Full disclosure: PeriodType has/had a tight coupling with a backend aggregation solution in one of my projects. I no longer work on that project, so I'm not as concerned anymore :).

Regarding the variants, currently we have short, and long. I've considered switching this to sm, lg and supporting md, xxs, xl, 2xl, etc (similar to Tailwind breakpoints) as needed. If we do switch to this variant naming, we should do the same for duration / Duration.

[jycouet]

breakpoint

I'm not a big big fan of short & long, I added default & custom, and now I think that it's "ok".
But I like even less sm, lg, md, ...

I think that it's hard to find 6 different levels of display of a year for example! (And then, at what breakpoint you go from yy to yyyy?) => I always forget levels & breakpoints... Ok you could customize... But then, it's too much of flexibility as of today. (My 2 cents)
d, dd, eee... All this is Day, what breakpoint is what?
I think that breakpoints don't fit, maybe I'm missing something?
Maybe you change my mind with some idea of "why"?

That's why I was thinking:

• Default => Ok, by default what do we want?
• Short => Let's have a good short version
• Long => Let's have a good long version
• Custom => to escape and do what you want

Often, Default is or short or long... (but not always the same).
I'm almost thinking: "do we even need short & long"?

dateDisplay

. If you're planning to support custom format strings in formatDate() that would be awesome too (it could still use dateFns, but then I guess we're back with dealing with locales in this case)

The custom, is already doing "a lot", and we can handle more and more cases if we have feedback.

I'll look into your commit and add different flags to help doing the same.

side node

The fns format "MM d, yyyy" is equivalent to intl format "d MM yyyy", because my "transform" takes care only about tokens, and locales + intl will do the right thing for US => "MM d, yyyy" 😉
I'm pretty happy about this cool trick. (You can also keep "MM d, yyyy")
Just not sure how to document this.

[techniq]

Breakpoint

Good points, I think it would be too much customization (especially to support). FWIW, it's not based on viewport/breakpoints, mostly usage based on available real estate / context. For example, LayerChart axis labels typically use short for dates since a simple MM/YY is enough context (and space constrained), and you typically use a tooltip to get more details on the date (get year, day of week, etc). This screenshot isn't the best example, but does show the concept a little.

So really short / long is based on usage, but I like default and custom. I wonder if we need custom but allow you to change short and long (similar to the number presets of decimal, currency, etc) and maybe let default allow you to specify short and long only? Trying to find the sweet spot of simplicity but not overly restrictive is a delicate balance. Thoughts?

dateDisplay

I need to get myself up to speed on DateTimeFormat and read through the PR closer, but it all sounds great. It looks like you are mapping unicode date tokens (aka date-fns format string) to DateTimeFormat options (i.e. 'long', 'short', '2-digit', 'numeric', narrow, undefined, ...). Looking on MDN, I was having trouble finding the full list of available options for each date part (year, month, day, etc). Did you find a good reference?

side node

Kind of what I mentioned above, but really we're translating unicode format strings and mapping them to DateTimeFormat options. Do this mean MM/dd/yyyy and MM-dd-yyyy and yyyy-MM-dd will also result in the same output string based on the locale, or can you still keep the explicit formatting? I'm assuming no, which is probably OK (and using date-fns format() directly when needed is probably best for this). How to document this (and if there is a better approach to make this more obvious if so). Basically all that matters is each part's definition, and not the order or separators.

Side note: I'm really liking how this is coming together and I REALLY appreciate you digging in. I knew it wouldn't be a small task, but this will be another huge improvement to Svelte UX. Thanks for all the effort!

[techniq]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

• main
  • PR Next release #167
    • PR [DateRange] Remove scrollIntoView for date selection components (month, year) #242
    • PR [MultiSelect] Add autoFocusSearch to opt into functionality, which MultiSelectMenu maintains #241
    • PR [Appbar] Add menuIcon prop and slot. Closes #235 #239
    • PR [Card] Add header, contents, and actions classes #238
    • PR Fix overriding elevation-# classes. Add elevation-none to remove elevation-#. Closes #233 #236
    • PR Refine PeriodType values and fix DateRange Bi-Week periodType support #217
    • PR Update all dependencies (and hopefully fix Safari) #213
    • PR Theme generator #192
    • PR Skeleton themes #184
    • PR Design tokens / Theme support (with dark mode) #146
    • PR 🕰️ NEW: formatDate #137 👈

This stack of pull requests is managed by Graphite.