mwmiller
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?
Trending in Questions
Other Trending Topics
Latest Hologram Threads
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #ai
- #graphql
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex











Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
bartblast
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
DateTimetimezone functions are impractical to transpile directly because they require timezone database libraries liketzdata(Elixir’s defaultUTCOnlyTimeZoneDatabaseonly 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:
This would return something like
"Europe/Warsaw", but theDateTimefunctions to format dates with that timezone won’t compile correctly yet for the reasons mentioned above.Two insights from your use case:
DateTimefunctionsHologram.Client,Hologram.Device,Hologram.Platform, etc. (you’d use something likeHologram.Client.timezone())Is this blocking you at the moment?
mwmiller
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.
bartblast
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.