Since you are still waiting I will try to give you some more background.
As mentioned in Steffen’s post, there are two things which trigger the update/2
callback. The first is a re-render from the parent, which will call it with whatever assigns are passed to the <.live_component />
invocation in the parent.
The second is the function send_update/3
, which can be used to send some values (assigns
) directly to a LiveComponent. It’s conceptually similar to message passing, but it’s not actually message passing because, as you might recall, LiveComponents exist within the same process as the parent. Docs here.
When you invoke send_update(MyLiveComponent, id: "some-id", key: "value")
then the component MyLiveComponent
with id some-id
on the page will receive update(%{key: "value"}, socket)
.
(I will point out for the record that this really isn’t Phoenix’s most intuitive API.)
In Steffen’s example, this send_update/3
functionality is used to rename an entry, as I think you have since discovered.
There is a third way for a LiveComponent to be re-rendered: receiving an event (like phx-click
). But unlike the first two, this does not call update/2
. Instead it invokes the handle_event/3
callback, which updates the assigns
accordingly (and then the component is rendered).
In the example, it is the event functionality which dynamically loads more children, which is why update/2
is not called in that case. If for some reason you wanted to trigger a reload of the children via, say, PubSub, you could create an update/2
case for that functionality and use send_update/3
to trigger it.
So back to the two update/2
clauses in the example. The first one, as we discussed earlier, pattern matches on an existing socket with an entry
already present. What this means, in effect, is that this first clause will only be invoked if the entry
has already been added to the LiveComponent. In other words, it will only be invoked after the first render.
Conversely, the second update/2
clause will only be invoked on the first render.
Now it’s very important to understand that there is a trick being used here: streams. Each LiveComponent in the example streams its children, and the child of a stream is only rendered immediately after a stream_*
call (like stream/4
or stream_insert/4
).
And so that is how we arrive at the behavior you have observed: as it turns out, nothing in Steffen’s example actually calls stream/4
on an entry’s children again after the initial render. And so nothing in this example ever triggers update/2
after the first render, unless you use send_update/3
(the rename operation).
That is why you have not observed the first clause being invoked.