If we include this I think it should be a service, with components being reserved for stuff that's visible on the page to the user.

Could you also add a short video showing it in use and tests if possible?

Hardcoding translations is really not the way we'd want to move forward. We have a great localization service for that. Also, can't the popup be handled at the dialog service level? It should also have the ability to swap out with a custom one, like the BytexDigital.Blazor.Components.CookieConsent does.

@danielchalmers

• Added video
• My thought was that a component is easier; A service would need to be transient which would then require a factory while a component is a single line
• This whole component is basically js, therefore tests aren't rly possible

@ScarletKuro The problem is that there is no way to catch and delay beforeunload as far as I know; this is handled by the browser directly. I could in theory show a custom popup on navigating away but I deliberately didn't do that as it would then show the browser dialog on close/reload and the MudDialog on navigation. This would probably confuse devs as their dialog is shown on some actions but not on all.

Translations: Hardcoded, as I wanted both dialogs to look as similar as possible (it's just the translation of the browser dialog text). But I could also just add a string field with a default english text if that's prefered.

I really like the usefulness of this functionality (I might need this in my SW) but I don't like the name. Here are some suggestions:

• MudNavigationGuard
• MudNavigationPrompt
• MudNavigationAlert
• MudExitPrompt

@henon As this also shows the dialog on tab close I would guess MudExitPrompt would be the most descriptive name. I will rename it to that after the other comments are resolved unless there are some other suggestions from @danielchalmers or @ScarletKuro.

Okay, now with the video it’s clearer what kind of dialog it is. I thought it was just a popup in the middle of the screen.

The localization can be solved in two ways:

• Send it to JS via an argument like await JsRuntime.InvokeAsync<bool>("mudNavigationConfirm.handleBeforeNavigation", Localizer[some_string_key]).
• Use a DotNetObjectReference that JS can invoke to receive the localized string from the localization service.

• This whole component is basically js, therefore tests aren't rly possible

We still can use some mocking to see if needed js calls are done on locationchange.

@ScarletKuro

• Can you take a look MudBlazor.MudExitPrompt.EnableAsync? I'm not rly sure if I use the localizer correctly
• I added a test but I wasn't able to trigger the location changing handler (NavigationManager.RegisterLocationChangingHandler(OnLocationChanging)) => do you know why it doesn't fire?

Fixed the tests. Not sure why this was necessary:

Context.Services.AddSingleton<NavigationManager>(s => s.GetRequiredService<BunitNavigationManager>());

This shouldn’t have been required, since new BunitContext() calls AddDefaultBunitContextServices, which already registers this exact service. So why it wasn’t available is unclear. Some JavaScript setup wasn’t done correctly as well.

Btw:

protected virtual async ValueTask DisposeAsyncCore()
{
    if (!Disabled && _navigatedAway)
    {
        await DisableAsync();
    }
}

Shouldn’t the component always be disposed when Disabled == false?
If handleBeforeNavigation returns false and the component is disposed, you won’t unsubscribe from beforeunload. Is that intentional?

Yeah, that is intentional; This would prevent the js from reacting to tab closed (that's also the reason the _navigatedAway flag exists)

Ah okay, thanks.
Just to be transparent, in January we’ll be creating official extensions (see #12323 (reply in thread)) and this will probably move there. Nothing needs to be done on your side, I’ll adjust the namespaces and code location myself.

It will mostly likely live here in this mono repo, and to make things easier, docs will reference it directly.