Cleanup of embedded Vaadin module


we have an existing code base for a standalone Vaadin application. We now have the (business) opportunity to provide some of our modules as part of a bigger (non-Vaadin) single-page web application.

By use of we manged to integrate our vaadin modules into the surrounding application based on the div integration approach.

Since we are just one of many other modules it is expected from our contributed module that it can be cleaned up in the process of switching to a different module (not from us). Our module might be called again later so it is also expected that it can be initialized again without problems (which also requires the cleanup).

The abovementioned article does not mention and I could not find any reference an unmounting a running vaadin app.

==> QUESTION: Is it possible and how can an embedded vaadin app be removed/cleaned up/unmounted? The goal is to avoid active listeners after the unmounting and the ability to start the module a second time.

Alternative solutions are of course welcome, too! Looking at und in the vaadin-client module at least one problem source is the missing handler registration removal of the various registered-only handlers (e.g., for ‘Window.addWindowClosingHandler(getWidget());’).

To detail the problem please find attached a minimal gradle-based spring boot application that embeds a minimal vaadin module into a mock javascript ‘SPA’.

The extracted folder from the zip file can be opend as an IntelliJ IDEA project (run or it can be run by ‘./gradlew bootRun’.

Once running the mock application is available per http://localhost:8080/index.html

Basic idea is to mock a SPA with three modules (‘Dummy Content 1’, ‘Dummy Content 2’, ‘Vaadin Content’). Clicking on a button will remove the content of the div node with id ‘content’ und either place a simple p(aragraph) node or the vaadin app under div tag (see javascript section in index.html).

The vaadin module will register a pop state listener as an example of a problematic cleanup issue.

After leaving the vaadin module (by clicking on one of the dummy modules) the vaadin backend is called to perform a registration removal of the previously registered pop state listener (which works fine).

Still, when looking at the javascript console (e.g., in Chrome) each URI change (by clicking the dummy module buttons) triggers vaadin-based frontend activity in the log (which is the still active frontend portion of the previously registered pop state listener, although it was removed in the backend). Looking at the code in it is clear that this is the still running javascript pop state registration, which is not removed by the call of ‘registration.remove();’ in the backend.

This problem applies to other possible listeners, too (see handlers for resize or close of window, scroll handler, …).

Additionally, a once called vaadin module can not be started a second time, because of the remainings from the first start (or at least I could not find a way to achieve it).

Best regards,
Thomas (57.1 KB)