Name spaces can conflict between sibling components. And that aside, this is more about avoiding the indirection of: handle_info/2 -> send_update/2 -> update/2.
The ability to add handle_info/2 to any LiveComponent and have it manage its own PubSub subscriptions, no manual routing required, is incredibly convenient.
I get that, but it does come with a cost - extra process plus an extra library with slightly different semantics. You don’t explain the original problem and what it looks like so I’m really just trying to understand how you got here.
To put those costs in perspective, an extra process isn’t expensive in elixir, and the library is a thin wrapper around Phoenix.LiveComponent, which you would only use if the new semantics prove valuable for you.
The original problem is in the first paragraph of the post if that helps 
I implemented the example app using both approaches in case you’d like to compare: Connected vs. Disconnected (vanilla LiveView). If it’s not worth the cost to you, totally get that, I shared in case anyone else was in search of better abstractions/patterns around LiveView.
I’m not sure if I agree with that statement because the LiveComponent state will also need to be stored, though not in a lightweight process, but in the parent LiveView. However, I don’t think that’s the main point of the discussion.
I understand that the initial problem you’re trying to solve is the communication between LiveComponents and PubSub. Since the discussion has shifted towards efficiency, I believe it would be beneficial to avoid creating a separate process to accommodate this feature. Instead, a “message broker” within the LiveView itself could handle this task, eliminating the need to spawn additional processes. This approach is more efficient and avoids introducing extra complexity to the LiveComponents.
I agree, it would be best if the extra process wasn’t necessary. However I wasn’t able to come up with a solution for automatically brokering messages in a single process, there are too many complications and you end up back where we started with manual message routing.
The extra process removes this complexity entirely, when it receives a message you know exactly the component its meant for, then it’s tagged as such and relayed to it. And this is opt-in, you wouldn’t use this for the majority of your components.
If you have specific ideas on implementing a single-process message broker I would love to hear them!
I would really like a pattern for this as well!
It would be very helpful to have handle_info for live_component as well.
Also having unmount for both live_view and live_component would be extra awesome!
Imagining having a live_component that subscribes to the pubsub on mount, and then be able to unsubscribe on unmount
And since the actual Pubsub subscription would be tied to the parent live_view process it would be unsubscribed automatically in case the process dies.
I had an idea to make live_components able to subscribe and receive Pubsub messages directly. But never a clean way to unsubscribe.
The reason why being able to unsubscribe using a unmount callback in the live_component would be if you had a widget implemented as a live_component and the widget was removed from the page in a render and you wanted to unsubscribe from the Pubsub without the parent having to manage the subscriptions and unsubscribe the ones that was owned by the child live_component.
In the solution I’ve implemented above, the component unsubscribes from PubSub automatically when it unmounts, as the process that manages it is stopped. So, no need for an unmount callback even
(Though I agree that would be nice to have for other reasons too.)
Hi!
Just looked thoroughly through your implmenetation and I would actually recommend this as a real candidate to the standard library 
Much more ergonomic with on_mount and handle_update the way you made it.
And the unmounting was also very nice
Good job!
Hi again!
Is the event that is triggered on DOM removal supposed to work?
https://github.com/jtormey/connected_component_demo/blob/b75fe70c3054313f027f2da280e91c7036b7a87f/lib/connected_component.ex#L166
This line specifically says to push a message to the server but using the now removed element as the target.
My current test shows that this gives this error:
utils.js:7 no component found matching phx-target of 7
Looking at the JS the binding checks if the component is still available in the DOM before trying to send the event to the server.
Since I really liked your approach I tried to fix it with the following:
I made a change where the connected_detach_event is sent to the parent instead with the cid as value:
connected_remove =
Phoenix.LiveView.JS.push(@connected_detach_event, value: %{cid: socket.assigns.myself.cid})
Updated the hook:
def on_mount(:default, _params, _session, socket) do
updated_socket =
socket
|> attach_hook(
:connected_handle_info,
:handle_info,
&SkyClientWeb.Components.ConnectedLiveComponent.connected_handle_info/2
)
|> attach_hook(
:connected_handle_event,
:handle_event,
&SkyClientWeb.Components.ConnectedLiveComponent.connected_handle_event/3
)
{:cont, updated_socket}
end
And updated the handler
defp detach_component_process(socket, cid) do
cid = %Phoenix.LiveComponent.CID{cid: cid}
send(self(), {@connected_detach, cid})
if component_pid = Process.get({@connected_process_dict, cid}) do
send(component_pid, :unmount)
Process.delete({@connected_process_dict, cid})
end
socket
end
Good catch! Thank you for implementing a fix for that.
The use of phx-remove itself was kind of a workaround, I went with this option because there is no LiveView-side API for knowing when a LiveComponent unmounts. If that ever changes then there’s opportunity to improve this further.