Animating list items with LiveView streams

You could do something like this:

<li
    :for={{id, j} <- @streams.jobs}
    id={id}
    class="border-2 p-2 h-fit flex flex-row justify-between overflow-hidden"
    phx-mounted={
        @insert && 
        JS.transition(
           {"first:ease-in duration-500", "first:opacity-0 first:p-0 first:h-0", "first:opacity-100"},
           time: 500
         )
    }
  >

Where you assign insert to false on initial mount and true before the first insert.

This is essentially what I ended up doing. Have a flag for that list, flip the flag appropriately to enable/disable animation. No render counting required as I was initially thinking.

This solves the animation when the item is inserted.

Any similar trick to conditionally trigger a phx-remove?

I want to avoid a useless animation when navigating away from a page, and only animate when removing items from a list. Current setup is a dropdown to select number of visible items that fires an event via phx-change, then the event handler updates query params (to save client state) and does a push_patch. The list is assigned in handle_params according to the query params (how many items to show).

While struggling with this too, I stumbled upon this thread and thought I should share my solution.

Basically my idea is to trigger UI events from their source (when the server wants to update the stream) and I think it’s less hacky than what’s proposed in this thread.

Here is my handle_info implementation, based on phoenix 1.8 usage of PubSub:

@impl true
  def handle_info({type, url = %URLs.URL{}}, socket) do
    id = "urls-#{url.id}"
    case type do
      :created ->
        if Map.equal?(socket.assigns.filters, %{}) do
          socket =
            socket
            |> stream_insert(:urls, url, at: 0)
            |> push_event("fade_in", %{id: id})
          {:noreply, socket}
        else
          # don't insert the new element if filters don't have default values
          {:noreply, socket}
        end
      :updated ->
        socket =
          socket
          |> stream_insert(:urls, url, update_only: true)
          |> push_event("fade_in", %{id: id})
        {:noreply, socket}
      :deleted ->
        socket =
          socket
          |> push_event("fade_out_and_remove", %{id: id})
        {:noreply, socket}
    end
  end

An important idea is not to call stream_delete on deletion, you’ll see why just below. (By the way this thing with socket.assigns.filters is because I use Flop and keep my filters in assigns to create return_to urls which keep the filtering.)

And here is the hook on each table row:

mounted() {
  this.handleEvent("fade_in", data => {
    if (data.id == this.el.id) {
      this.js().transition(
        this.el,
        ["ease-out duration-200", "opacity-0 scale-95", "opacity-100 scale-100"]
      );
    }
  });
  this.handleEvent("fade_out_and_remove", data => {
    if (data.id == this.el.id) {
      this.js().hide(
        this.el,
        {"transition": ["ease-out duration-200", "opacity-100 scale-100", "opacity-0 scale-95"]}
      );
      setTimeout(() => {
        this.el.remove();
      }, "200");
    }
  });
}

Note that you can’t send an event to a specific hook (or at least I didn’t find out how), so you need to filter its destination directly inside the hook.

About events:

• when an element of the stream is added or updated, the server sends an event which triggers a fade_in transition on its table row
• when an object is deleted, the server sends an event which triggers a fade_out transition and then deletes the HTML element. This is basically means I re-implemented the UI side of stream_delete without removing the element from the actual stream. But that’s not a big deal in my opinion since it will be refreshed sooner or later. Also note that you could also keep the HTML element, it would be hidden anyway thanks to js().hide().

Hope this helps!

Nice solution ! Explicit server-pushed events give much more granular control than phx-mounted and phx-remove.

I think this is very correct.

Sometimes I choose to use a global event listener, so that I have a single listener that applies the action to an element given a selector, instead of multiple instances of the hook. Note that when server sent events bubble up to the window they get the phx: prefix (JavaScript interoperability — Phoenix LiveView v1.2.5).

For example, in app.js:

window.addEventListener("phx:fade_in", event => {
  const el = document.querySelector(event.detail.selector);
  if (!el) return;
  liveSocket.js().transition(el, ["ease-out duration-200", "opacity-0 scale-95", "opacity-100 scale-100"]);
});

On the server side:

    socket
    |> push_event("fade_in", %{"selector" => "#urls-#{url.id}"})

A more generic listener could even exec any set of JS commands stored in an attribute (or sent along the event payload):

window.addEventListener("phx:exec", event => {
  const el = document.querySelector(event.detail.selector);
  if (!el) return;
  liveSocket.execJS(el, event.detail.js || el.getAttribute(event.detail.attr));
});

On the server side:

<div
  id={@id}
  data-phx-show={JS.transition({"ease-out duration-200", "opacity-0 scale-95", "opacity-100 scale-100"})}
>...</div>

    socket
    |> push_event("exec", %{
      "selector" => "#urls-#{url.id}",
      "attr" => "data-phx-show"
    })

Or (see Make `JS.t()` a public data structure, or json serializable):

    socket
    |> push_event("exec", %{
      "selector" => "#urls-#{url.id}",
      "js" =>
        JS.transition({"ease-out duration-200", "opacity-0 scale-95", "opacity-100 scale-100"}).ops
        |> JSON.encode!()
    })

Very interesting, thank you!

Edit: that’s what I ended up doing to reduce JS load on the browser (also it allows to send any transition to any DOM element, which is nice).

By the way, View Transitions actually make these kind of transitions trivial, see this example here: Same-document view transitions for single-page applications  |  View Transitions  |  Chrome for Developers

Currently not supported in live_view yet, but if my proposal can get enough attention, we might make it possible soon: