I’m wondering if there is a way to use some Javascript client APIs via Hologram without writing some kind of pure JS hooks.
I want to add some date information to my pages. A notoriously sticky wicket, to be sure. However my needs are fairly simple. I have UTC instants in my data source. I’d like to display them as local times for user convenience.
I don’t like pushing client concerns to the server or vice-versa. So I’d rather not round trip the client’s TZ to the server to create a date string in Elixir which might not even match their locale’s preferred formatting. Instead, I’d like to push the common-to-all-clients UTC instants to the clients and allow them to format it as desired.
Is this just something for which I will have to write some Javascript? Or is there a clever workaround of which I cannot think?
1 Like
Web API wrappers are planned, but locale and time handling need a special isomorphic-aware approach. For your use case, you’d probably want to server-render with a default timezone first, then update client-side - otherwise you’d have to render all dates only after client load.
Some DateTime timezone functions are impractical to transpile directly because they require timezone database libraries like tzdata (Elixir’s default UTCOnlyTimeZoneDatabase only supports UTC). These libraries contain large IANA timezone databases that would bloat the JS bundle. Instead, it’s better to port them manually using Web APIs underneath while maintaining the same Elixir API.
You could theoretically get the timezone like this now:
timezone = ~JS"return Type.string(Intl.DateTimeFormat().resolvedOptions().timeZone)"
This would return something like "Europe/Warsaw", but the DateTime functions to format dates with that timezone won’t compile correctly yet for the reasons mentioned above.
Two insights from your use case:
- I need to manually port key
DateTime functions
- There’s probably a need for client-side system info modules like
Hologram.Client, Hologram.Device, Hologram.Platform, etc. (you’d use something like Hologram.Client.timezone())
Is this blocking you at the moment?
2 Likes
Thanks for the explanation! This is actually further along than I expected already.
It’s a silly little side project and my explorations of what’s possible. It could not matter less in the grand scheme of things.
1 Like
I won’t prioritize the DateTime porting immediately then, but I’ll keep it high in the backlog since others will likely hit this pattern too.
3 Likes