LiveView + WebComponents re-render issue

Questions / Help
,
1

Hello :wave:

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..

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).

relative_time_bug

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

1 Like
2

phx-update: "ignore" does this trick, though I don’t understand why.

3

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

1 Like
4

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.

5

:thinking: Yes, I get that, only these elements are in fact removed and re-rendered (see the list order change in the gif), on a paginated table it could even be entirely different values. So I’m wondering what part exactly isn’t updated anymore (shadow dom? but as said, these should be new DOM nodes as far as I can tell), or otherwise for what reason the phx-update changes anything. Or am I outdated and LV now has some magic “list reordering” logic that can re-order DOM nodes from a collection?

6

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.

1 Like
7

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!

1 Like
8

:thinking: hmm I noticed something: When I manually (in the inspector) add an attribute to the <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” time-elements/relative-time-element.ts at 40f3d1abb9a1271607182704fa949b5867f94496 · github/time-elements · GitHub, but this event doesn’t fire). However, I now wonder even more how phx-update=ignore fixes 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.