new lifecycle onAfterUnmount

[Alfred-Skyblue]

When we remove an element using el.remove(), the components contained within that element do not execute the onUnmounted lifecycle. I would like to add a new lifecycle called onAfterUnmounted that triggers after the component's el or the element containing the current component is removed from the DOM tree. Otherwise, when we manually remove DOM elements, it causes memory leaks in the child components contained within that element.

demo

In the demo above, we demonstrate the usage scenario where onUnmounted is not triggered when we use el.remove() to delete elements.

PR

[Justineo]

I believe we shouldn’t manually remove elements that are created by Vue. What is the use case for this?

[Alfred-Skyblue]

For example, in a back-office management system, I am using imperative rendering for a dialog component. Since it is not rendered within the template, the dialog does not trigger the unmounted event when the current component instance is destroyed. The dialog component covers the entire screen and is mounted to the body element. However, due to certain reasons such as a change in permissions or an expired token, I need to redirect the route to the login page. During this redirection process, I need to manually remove the DOM element that contains the dialog. Many UI libraries, such as Element Plus MessageBox and Ant Design Vue Modal, utilize imperative rendering for components.

[Justineo]

This is rather a matter of API design of component libraries I think. The real problem is that these imperatively triggered dialogs do not provide a way to safely dispose themselves.

On the other hand, using MutationObserver to observe the output of the rendering logic looks very unsafe to me. DOM elements can be removed from its parent element for various reasons, ie. due to v-if switches, portals, or DOM manipulation performed by users or third party libraries.

If Vue was adding a onAfterUnmount hook, it should be when Vue itself has done removing a component's node from the DOM (rather than it found out from the output that the node is gone). This has a more legit use case IMO. eg. when a component is v-ifed out but inside a <Transition>, we may want to dispose its contents after transition completes (disposing third party chart instance, rich-text editors, etc.), otherwise we will see the content disappears immediately after the component starts to fade/slide out.