When LWC that is used in Flow Screen is destroyed?

Question

I need to detect when the LWC is destroyed, so far I haven't noticed that a disconnectedCallback has ever triggered on the LWC that is used in Screen on Flow. This creates a lot of problems because I want to unregister pubsub listeners on disconnectedCallback. Surprisingly, disconnectedCallback is not triggered even when the user leaves the flow and goes to a completely different page on community.

Answer 1

We found exactly the same '5 navigations' behaviour described by Aditya when implementing an LWC that contained a VF page in an iFrame.

We needed the LWC and VF page to communicate, and were doing that by using window.postMessage, and registering Window level event listeners.

In the LWC we would deregister the event listener in the disconnectedCallback.

However, we were finding that we were getting messages processed multiple times, and since the LWC and VF page would sometimes make callbacks to each other, we were seeing some messages spiral out of control.

We didn't like the idea of deregistering the event listeners when the LWC was still in the DOM though, since this would break the back button behaviour.

Instead, when the LWC is created, it defines a random identifier for itself. It then passes this into the VF page, on the URL.

Whenever the VF page issues the window level event it includes this identifier.

Whenever an LWC receives an event, it checks the identifier to see if it was the intended recipient, and only processes the message if it is.

The result is that the listeners can remain registered until the LWC is removed from the DOM, messages don't spiral and the back button behaviour remains working.

This example may be a very particular scenario, but I hope it's useful nontheless.

Answer 2

Its slightly tricky. disconnectedCallback is only called if a component is removed from the DOM, and this depends on the experience you are in.

1. Lightning Experience keeps the 5 previous pages you've visited alive to provide instant backward navigation (using the browser's back button). So in LEX if you navigate away from a page or record to a different page, the page isn't destroyed, so your LWC is also not destroyed. Once you navigate to the 6th page, then the 1st page you visited is destroyed and disconnectedCallback is called. It is also important to remember that if you're re-visiting any of the 5 pages that are alive (using the browser back button), connectedCallback is not called again. However, if you go to a page by clicking its tab or link, the page would destroy and re-create the components.

2. In Communities/Experience Cloud however, a page is destroyed when you navigate away to a different tab (not browser tab). So disconnectedCallback is immediately called.

3. In Flow Runtime, a component is disconnected whenever you navigate away from that screen.

I just personally tried using an LWC in both the community and flow, and disconnectedCallback from both the flow screen component and page-level component are called when I navigate away to a different community page.

Now in cases where disconnectedCallback isn't called when you want, there is a workaround you can use: You can query for an element in your HTML template thats always shown to the user i.e., not within any if:true or if:false directives, and check it's height and width. For example

this.template.querySelector('div').offsetWidth

If their height and width are non-zero, that means your component is visible to the user. If it is 0, it means your component is not visible to the user (meaning that they navigated away from the page on which it is shown). Depending on this, you can perform steps like unregistering listeners. You may have to put this logic inside a setInterval block to keep checking for component visibility to re-connect listeners. So your logic to connect/disconnect from pubsub lives both inside connected/disconnectedCallback and the setInterval function.

I also made a short video explaining this concept.