You basically need a piece of code which filters the pubsub events based on the currently viewed product. I don’t think theres a much better solution to what you have - using handle_params. You can subscribe to receive all the pubsub messages of the background jobs and filter in handle_info based on the identifier of the currently viewed product. This avoids the unsubscribe/subscribe dance but introduces more messages in the mailbox.

Unfortunately LiveView lacks the primitives needed to perform generalized incremental computation. For example React has useEffect() and useMemo(), but Phoenix lacks even a full implementation of the older (inferior) lifecycle paradigm: it has mount() and update(), but no unmount().

This makes interop between declarative and imperative code rather… difficult.

Of course you can abandon the incremental approach entirely. The root of the LiveView can subscribe to everything and then meter updates out to individual components.

def handle_info({:product_update, message}, socket) do
  send_update Components.ProductA, id: "product-a", message: message
  send_update Components.ProductB, id: "product-b", message: message
  send_update Components.ProductSidebar, id: "product-sidebar", message: message
  # ...
end

But now, and this kind-of hints at the problem, the structure of your application has become entirely rigid and static. Yes you can unmount A or B and the messages will be ignored, but you have lost the ability to dynamically subscribe. The ability to dynamically mount/unmount components and incrementalize computation is the fundamental raison d’etre for React-style engines, and LiveView is unfortunately derelict of its duty in this department.

If you’re clever you might think you could transmit subscriptions from dynamically mounted components back up to the root. Believe me, I thought that too. But putting aside for the moment that component ids in Phoenix don’t compose (an unrelated issue), this is still insufficient. You cannot tell if a component has been unmounted, so there is no way for a component to clean up after itself.

Right about now some of you may be getting some ideas about how you might hook into the code that leads to an unmount, upstream, and unsubscribe there. Like at the router level, or in response to an event. Let me stop you right there: you are giving up not only incrementalization, but declarative programming as a whole. You are writing imperative code and will be cursed by the gods. Many stronger than you have ventured down this path, and all have fallen. Abandon hope, all ye who enter here.

To be clear, there is no fundamental or technical reason why LiveView cannot provide this functionality. Instead I think it’s mostly a cultural difference; that is to say, most of the devs using LiveView do not understand or need any of this, and would probably get by just fine with something like HTMX if they didn’t happen to be writing Elixir. I used to think that it would be a good idea to extend LiveView with more incremental functionality, but in reality the depth of the changes needed would likely serve to annoy those who don’t want, need, or understand them in the first place. Plus it’s not like I’m volunteering to do the work.

It will likely be easier to write a new framework from scratch.

(And in general I do think it would be nice to have more app frameworks in Elixir, which is why I’m rooting for Hologram!)

TLDR: No, not really.

As far as I know, your intuition is right, implement conditional deregistration and registration as part of handle_params/3 (possibly extracted into a defp helper.)

If you don’t already, store the current product ID in an assign. You can assign it to nil on mount/3, so that in handle_params/3 you can easily distinguish if you just started and there’s no state to clean up, or if you navigated between products. Assign the current product ID in the handle_params/3 callback.

Don’t forget to check the current product ID in your handle_info/2 callback, and discard messages unrelated to the current product.