The problem here is not so much optimization of software performance (though of course that matters) but rather optimization of developer performance. That is: not turning your codebase into a spaghetti disaster. We are all programmers on here and we all know what this feels like, so I don’t need to justify this further.
The question the OP actually asked is a question of resource management by components. How can a component allocate a resource (in this case PubSub, but it could be literally anything) and then release it when the component is unmounted. Ideally declaratively and idiomatically within LiveView.
What I have explained (hopefully clearly, but maybe not idk) is that it is not possible to solve this properly in LiveView because components (including the root LV, which is also a component) do not have an unmount callback. It has been proposed several times but so far no dice.
I want to be very clear: there is nothing wrong with your or @krasenyp 's suggestion to filter events on the receiving end. This is a legitimate technique, and that’s what I was getting at with the Slack bit at the end. There are times when you can and should do this.
However, the filtering trick does not solve the problem in the OP. The inability to manage resources will come back to haunt you either way. There is a reason most frameworks have some sort of unmount. React post-Hooks came up with something even better (the useEffect continuation/slicing trick) which I also described, and which is also described in much more detail in one of those articles I linked.
I will try to give one last example. Say you have a LiveView at /products, like the OP, and it receives events. Now say you have another completely unrelated page in your app, like /settings. You make use of the live navigation feature to allow users to navigate between pages over the socket (as the OP did).
A user:
- Loads
/products/1and mounts aProductLiveView - Subscribes to the
"product_updates"PubSub channel - Clicks on a link to
/settingswhich mounts theSettingsLV in the same process
The Settings LiveView now receives product updates.
Put aside all performance concerns here and just trust your experience. Can you honestly say that you think this sounds like a good idea? Can you honestly say that down the road, when your app has 100 pages, a bunch random events bouncing around unpredictably between all of them won’t cause confusion or bugs?
It is not premature optimization to design systems properly from the start, and this is not an edge case. There is no easy way to paper over this with some hack, because it will always come back. It will come back with components, it will come back with other types of resources, and so on.
The OP asked for an elegant solution and I don’t believe there is one. If they had asked about React (or really any other app framework) I could have just handed them the useEffect() example and that would be it.
If anyone else has an actual solution that I haven’t thought of please post it. Filtering, while entirely valid, does not solve this problem.
