AFAIK all of these JS frameworks give you “unmount” lifecycle hooks on the client side, not on the server. They are all fundamentally different from LiveView’s operation model.
Yet DOM patching happens client side. You can’t know a component will be unmounted server side without application knowledge, e.g. by knowing a certain assign affects the presence of a certain part of the HTML template.
That’s because it’s on the client that the decision is made whether a node moved across the DOM tree, a node content got replaced and the container is reused (i.e. no phx-remove event), or a DOM node is actually removed.
On the client side LiveView provides at least two ways to hook into the lifecycle of arbitrary DOM nodes (that don’t need to match 1:1 to any server side idea of “component”), in particular related to unmount: phx-remove and client hooks destroyed callback.
Note that the server side idea of a component (be it a function component or LiveComponent) is detached from the lifecycle of client-side DOM nodes, and they are not mapped 1:1.
The OP doesn’t mention using LiveComponent, so bringing back to elegant ways of managing state on the server side lifecycle, what I’ve seen and done in cases like that is use explicit functions called from the appropriate LiveView callbacks:
For route changes in the same LV it’s handle_params. We could also have code in handle_event, for instance when form changes (e.g. filters) affect the state of the LV. Imagine a filter on the client would affect the list of desired PubSub subscriptions. I’ve given an example of handle_event → push_patch → handle_params in another thread, which demonstrates how to react to arbitrary page events, update/store state in the URL and re-render keeping everything consistently in sync.
(The same idea can be used to manage PubSub subscriptions in response to arbitrary events keeping state in the URL in sync)
-–
We’re beyond the scope of the OP 
