Yes Jose, it seems to work. Minimal example:
Mix.install([{:phoenix_playground, "~> 0.1.3"}])
defmodule DemoComponent do
use Phoenix.LiveComponent
def render(assigns) do
~H"""
<li>
Count: <span><%= @count %></span>,
item: <%= @item.name %>
</li>
"""
end
end
defmodule DemoLive do
use Phoenix.LiveView
def render(assigns) do
~H"""
<button phx-click="randomize">randomize</button>
<ul>
<.live_component
:for={item <- @items}
id={item.id}
module={DemoComponent}
count={@count}
item={item}
/>
</ul>
"""
end
def mount(_params, _session, socket) do
socket = socket |> assign(:count, 0) |> assign(:items, random_items())
{:ok, assign(socket, :count, 0)}
end
def handle_event("randomize", _params, socket) do
{:noreply, socket |> assign(:items, random_items()) |> update(:count, &(&1 + 1))}
end
def random_items() do
1..11
|> Enum.take_random(10)
|> Enum.map(&%{id: &1, name: "New#{&1 + 1}"})
end
end
PhoenixPlayground.start(live: DemoLive)
and this is a payload from the console
it updates only dynamic parts that changed, and it seem to reorder correctly as well. So I’d say it’s what we want when it comes to the payload size! 
Just, I’d like to understand the tradeoffs. If I’m correct:
- it keeps the assigns separately for each live_component, possibly doubling memory consumption
- it keeps a list of assigned IDs.
It seems these are not kept in the socket but somewhere else in the process state. I’ll look how exactly they’re handled currently soon.
So the questions:
- how we could make the API more approachable? I like your suggestion of adding an attribute that will make any function component
live_component. Probably it shouldn’t be id, though, since it might be used simply to have it in DOM. Maybe something likephx-component-id? - I know it might be a big change, but would it be possible to avoid storing assigns separately for each live_component created that way and instead rely on
__changed__to detect what should be updated?
Because that’s the only thing we need old assigns for, right?
