UnloadObserver should always send an event before unloading

[jflamy]

I would like to use the unload observer to unregister components (my application uses an event bus, and I would like my components to be removed right away on close instead of waiting for the detach event).
It would be nice to be able to register/unregister components to be notified when navigating. Maybe just a coding example would do.

[vaadin-miki]

UnloadObserver is intended to provide a callback to the server when the user closes the tab (or browser window) or manually navigates away. Navigation lifecycle is a standard feature of Vaadin, as described here: https://vaadin.com/docs/flow/routing/tutorial-routing-lifecycle.html - so I would expect what you are trying to achieve can be done through that.

I admit I have not tested the component well enough, so it is very well possible that the event triggers when navigating to somewhere within the app or in some other weird cases. I will investigate and update this ticket accordingly.

[jflamy]

The "onbeforeleave" navigation events don't trigger when the window is closed. So the components on a page stay there until the onDetach triggers a few minutes later. I need something that will push the registrations on a stack and pop them when navigating to another page, or when the unload of the window occurs. Le lun. 22 juin 2020 à 15:45, Miki <notifications@github.com> a écrit :

…

UnloadObserver is intended to provide a callback to the server when the user closes the tab (or browser window) or manually navigates away. Navigation lifecycle is a standard feature of Vaadin, as described here: https://vaadin.com/docs/flow/routing/tutorial-routing-lifecycle.html - so I would expect what you are trying to achieve can be done through that. I admit I have not tested the component well enough, so it is very well possible that the event triggers when navigating to somewhere within the app or in some other weird cases. I will investigate and update this ticket accordingly. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#170 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFFWB4FMSNWBF4E74KYDILRX6YHFANCNFSM4OE26CIQ> .

[vaadin-miki]

Alrighty. I think that with the fix of #173 it should be possible to get the parent component in which UnloadObserver resides. In that case you should be able to detach components manually e.g. by removing them from the layout or taking them from some other globally available place (not sure if there is a better approach, and I think having each component listen to unload events is in general a bad idea).

I will try to come up with changes to the demo app to support multiple views (see #174) and at the same time I can have the unload trigger e.g. log the components in the current view.

[jflamy]

Agreed. Le mar. 23 juin 2020 à 07:16, Miki <notifications@github.com> a écrit :

…

Alrighty. I think that with the fix of #173 <#173> it should be possible to get the parent component in which UnloadObserver resides. In that case you should be able to detach components manually e.g. by removing them from the layout or taking them from some other globally available place (not sure if there is a better approach, and I think having each component listen to unload events is in general a bad idea). I will try to come up with changes to the demo app to support multiple views (see #174 <#174>) and at the same time I can have the unload trigger e.g. log the components in the current view. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#170 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFFWB5JA3QXDUK3G3KPKGDRYCFKLANCNFSM4OE26CIQ> .

[vaadin-miki]

While I am working on #173, I had an idea. Currently the only config for UnloadObserver is to either:

• display a confirmation window and register an attempt (both successful or not)
• do nothing

I think it would make sense to inform server also when the unload happened. I think this is what would help you achieve your goal of unloading components when the app is closed - no need for query here. Is my thinking correct?

[jflamy]

I will need to manage a list of all objects that I need to clean up when the UI they being to closes. I will need to manage a map<UI,Registration> So I need to know which UI is closing. jfl, de mon téléphone

…

Le 24 juin 2020 à 12:25, Miki ***@***.***> a écrit :  While I am working on #173, I had an idea. Currently the only config for UnloadObserver is to either: display a confirmation window and register an attempt (both successful or not) do nothing I think it would make sense to inform server also when the unload happened. I think this is what would help you achieve your goal of unloading components when the app is closed - no need for query here. Is my thinking correct? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[vaadin-miki]

Alright. I did some testing. It is impossible to contact the server on unload event, as it is not available. However, it is possible to call server without displaying a prompt to the user. So, UnloadObserver will do this by default, and the event now has a flag isBecauseOfQuerying which will be true when the user was shown prompt, and false when the event just happened and the page has been unloaded (unless there has been something else preventing it from unloading, of course).

This has a drawback: it is impossible to find out if the page has been closed because user has agreed to leave it. I think though it is acceptable as is. The drawback can be fixed by #176 if there is anyone willing to work on it, I am not skilled in JS enough to fix it.

Anyway, the above behaviour should fit your use case @jflamy - when the event is called the UnloadObserver is attached to some parent, so you can probably figure out everything you need. This will be included in version 0.7.1 which I hope to release early next week. Of course if you want, you could build the add-on yourself from development branch once this is merged, and then test it. It would be much appreciated :)

[jflamy]

Excellent. I will be looking at it.

…

------ Original Message ------ From: "Miki" <notifications@github.com> To: "vaadin-miki/super-fields" <super-fields@noreply.github.com> Cc: "Jean-François Lamy" <jf@jflamy.dev>; "Mention" <mention@noreply.github.com> Sent: 2020-06-26 5:35:24 PM Subject: Re: [vaadin-miki/super-fields] UnloadObserver should always send an event before unloading (#170)

Alright. I did some testing. It is impossible to contact the server on unload event, as it is not available. However, it is possible to call server without displaying a prompt to the user. So, UnloadObserver will do this by default, and the event now has a flag isBecauseOfQuerying which will be true when the user was shown prompt, and false when the event just happened and the page has been unloaded (unless there has been something else preventing it from unloading, of course). This has a drawback: it is impossible to find out if the page has been closed because user has agreed to leave it. I think though it is acceptable as is. The drawback can be fixed by #176 <#176> if there is anyone willing to work on it, I am not skilled in JS enough to fix it. Anyway, the above behaviour should fit your use case @jflamy <https://github.com/jflamy> - when the event is called the UnloadObserver is attached to some parent, so you can probably figure out everything you need. This will be included in version 0.7.1 which I hope to release early next week. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#170 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFFWB2BDM6CV2QHPIOQCODRYUIBZANCNFSM4OE26CIQ>.