maltoe
Hello 
We have a small table-based index page based on LiveView, which displays (among other data) some timestamps in “relative” format using <relative-time> from GitHub - github/relative-time-element: Web component extensions to the standard <time> element. · GitHub.
This works great on first render but as soon as the table content is updated via the websocket, the time elements are re-rendered with their “fallback” content (the timestamp).
The markup is generated using this function:
def relative_time(datetime)
{:ok, humanized} = MyApp.Cldr.DateTime.to_string(datetime, format: :short)
content_tag(:"relative-time", humanized, datetime: to_string(datetime))
end
Does anyone have an idea? I’m pretty sure the web components aren’t initialized properly (i.e. some JS doesn’t run), but I wonder why that is?
Best,
malte
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Phoenix, LiveView, multimedia pipelines, distributed systems. 400 engineers, Elixir since 2017. Available for hire.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 7 to 1- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
maltoe
<relative-time>element and then re-order the table, the attribute sticks with the element in that row, which leads me to believe morphdom is actually smart enough to replace only the<relative-time>'s content instead of re-creating the DOM node. Which would also explain why the JS doesn’t convert the timestamp (it is triggered when the web component is “connected” relative-time-element/src/relative-time-element.ts at 40f3d1abb9a1271607182704fa949b5867f94496 · github/relative-time-element · GitHub, but this event doesn’t fire). However, I now wonder even more howphx-update=ignorefixes it in this case. The content of these elements is clearly updated (I see the content change), but they are now correctly shown in relative time.just for completeness: Tried it with paginated result set again (so elements are destroyed and re-created) and it works. The ordering link is a
live_patch, if that matters.maltoe
Yes, the
phx-update="ignore"attributes went on the<relative-time>elements.Looking at the ws packages it seems that LV is sending the entire table with each re-ordering, so I suppose the “moving around” of elements you describe is magic that happens in morphdom. That is quite impressive.
Thanks for your help!
kelvinst
Hmmmmm, I’m not really sure, but I suspect that placing
phx-update="ignore"on whatever tag is just going to guarantee that tag or its contents is not going to be changed anymore, or at least that is what I would expect to happen. But as far as I understood, you marked the individual datetime elements with that, and not the table that contains them, and what’s changing when you click to reorder is that table, not the actual date time elements, they stay the same, they are just moved around.maltoe
phx-updatechanges anything. Or am I outdated and LV now has some magic “list reordering” logic that can re-order DOM nodes from a collection?kelvinst
phx-update: "ignore"tells the websocket to not update those elements anymore, that’s probably why that’s fixing, as the content to those tags is not changing.kelvinst
Well, basically what you want to do is to create a phx-hook to re run the time-elements code when your nodes are updated by the websocket. Checkout the client hooks docs
maltoe
phx-update: "ignore"does this trick, though I don’t understand why.https://github.com/phoenixframework/phoenix_live_view/issues/285