A fragment-based Dialog is not destroyed/reset in UI5 upon leaving the view

Question

The official UI5 documentation claims:

[...] We want to make sure that the memory allocated for this helper object is freed up when the component is destroyed. Otherwise our application may cause memory leaks.

To do so, we use the exit hook. The OpenUI5 framework calls the function assigned to exit when destroying the component. We call the destroy function of HelloDialog to clean up the helper class and end its lifecycle. Nevertheless, the instance itself would still exist in the browser memory. Therefore we delete our reference to the HelloDialog instance by calling delete this._helloDialog and the garbage collection of the browser can clean up its memory.

I've set a break point on this._helloDialog.destroy(); inside of

exit() {
    this._helloDialog.destroy();
    delete this._helloDialog;
}

And I expect that the break point will be triggered on leaving the view, which hosts this dialog. In fact, when I switched the view nothing happened, it looks like exit() wasn't executed at all.

Besides that, I've paid attention that after opening the dialog, typing a text there, closing and then reopening the dialog, the previously typed text remains untouched.

Such behavior forces me to assume that the dialog object is never released and it might be a potential place for the memory leak.

My questions:

1. Why the exit hook is not triggered when I leave the view, where this dialog had been defined?

2. Are there any best practices / common patterns for «resetting» the dialog's content in UI5?

Answer 1

Why the exit hook is not triggered when I leave the view, where this dialog had been defined?

Destroying a dialog has been always a somewhat questionable practice: when the user, for example, decides to open it again; the dialog with its entire tree of child nodes needs to be recreated and rerendered on the DOM, every single control there needs to be re-registered on the Core, as well as their events on the UIArea, models need to be propagated firing all kinds of events in the meantime, memory needs to be re-allocated, etc, etc.. To sum it up - it's quite costly.

The exit-hook, which is a low-level API, is however triggered automatically when the application calls destroy() on the ManagedObject. For example, the Fiori Launchpad automatically calls currentUIComponent.destroy() when the user navigates to Home triggering the exit-hook on every child element including the dialog.

Are there any best practices / common patterns for «resetting» the dialog's content in UI5?

Yes, see my answer on How to reset reset all screen's control values.