Blazor Exit Lifecycle Method with Active WebSocket Connection

[TheFanatr]

Purpose

Certain Blazor applications could benefit from having a lifecycle method for when the component is being navigated away from, while JavaScript interop is still available. Using the @implements IDisposable pattern will allow code to execute when the component is being disposed, but it would be nice if it would be possible to delay something like an unload to execute some final interop that requires an active connection. A possible usage of this could be logging something before the site is navigated away, or showing an alert from the server.

Suggestion

I'd like the addition of another lifecycle method which would be invoked and let to run to completion before the disposal of a component. The possible names for this method are OnBeforeDispose, OnExit, and OnClose, with async variants provided as well.

Alternatives

Another possibility would be the provisioning of a state control method called KeepAlive(ref object o), which, when invoked, will lock further execution of disposing logic until the provided object is null. An overload could also be provided for a TimeSpan instance for how long the process should be delayed. I think these solutions could end up being sub-optimal in terms of being misused, and could be considerably delicate, especially in the ref object parameter overload's case.

Additional Context

The reason I brought this up is because I tried logging something to the browser console in IDisposable.Dispose() and it did not work.

[SteveSandersonMS]

I'm afraid that browsers don't run any asynchronous code during the window unload event. They will trigger the window.onunload event, from which you can run synchronous code, but as soon as you yield the thread the page will be torn down and your application stops running.

As such, Blazor already has lifecycle methods for all the possible cases. You can already start an asynchronous process from a Dispose method (e.g., invoke some async method from it), which works fine as long as it's just the component being disposed and not the whole app being unloaded. You shouldn't expect the browser to keep your application code running once the user has navigated away.

Note that separately, we will implement IAsyncDisposable support, but this doesn't change the underlying reality that browsers will kill your application synchronously once the user navigates away.

[TheFanatr]

Hello @SteveSandersonMS,
Unfortunately, I think you may have misunderstood my request. I realize that a browser-side unload can’t be delayed for this purpose, what I am asking is for when the componenet is no longer rendered on the server and is about to be disposed. This would include if a component was conditionally rendered and the state changed so that it is culled from the DOM and the instance is disposed; at this point the connection is still active, and the server still has the ability to keep the component instance alive a little longer for an asynchronous interop request to complete. I have not had success executing such operations on dispose.

[SteveSandersonMS]

Thanks for clarifying, @TheFanatr! That does make more sense now.

We don't do anything to stop your background tasks (launched from Dispose or anywhere else) from running, so I don't know why you'd be having trouble with them. If you can produce a minimal repro of something that should work but doesn't, we'd certainly take a look.

If you are able to repro a problem clearly, it would be best if you filed a new issue describing it as a bug rather than appending to this issue which already has a long and potentially confusing conversation in it!