calculate children_cids in Phoenix.LiveView.Debug

[SteffenDE]

Relates to #4357.
Relates to #4356.

[SteffenDE]

Feedback from Codex

  - [P2] Avoid deriving children from stale parent links — /Users/steffen/oss/phoenix_live_view/lib/phoenix_live_view/channel.ex:435-435
    When a component stops rendering a nested child, that child can remain in components until the client sends cids_destroyed, and no new pending entry is emitted to clear its old :parent_cid. Grouping all components by this cached value makes Debug.live_components/1 report removed
    children under the old parent, for example after toggling a <.live_component :if={@show}> off inside a parent component.

I think this is acceptable.

[josevalim]

Maybe a simpler approach is to store it in socket.private.parent_cid instead?

[SteffenDE]

I don't understand this comment. We store it in socket.private

https://github.com/phoenixframework/phoenix_live_view/pull/4358/changes#diff-19b2d930da850e275050448e8971f44bd28666d0b1e93efee8a0369d35b2a8a0R938

[josevalim]

Sorry. Basically I wanted to avoid changing the {cid, id, new?, new_assigns} tuples by storing it somewhere else. Either permanently in the socket, as part of new?, or so forth.

[SteffenDE]

I don't see an obviously better way. We only have the child socket later in render_pending_components. This line you commented on is the parent socket.

We could make it

{cid, id, %{new?: new?, parent_cid: parent_cid}, new_assigns}

but I don't think it's much better and we have an extra map. If we're not happy with this, we can also keep things as is. So far nobody complained that children_cids can be incomplete 😅

[josevalim]

Yeah, I think both approaches will be somewhat equivalent by the end of the day. There is the additional traversal in the other one but we may be fine. Your call!