diff --git a/aspnetcore/blazor/includes/js-interop/js-collocation.md b/aspnetcore/blazor/includes/js-interop/js-collocation.md index fbc33d311c8e..647b8b29cc95 100644 --- a/aspnetcore/blazor/includes/js-interop/js-collocation.md +++ b/aspnetcore/blazor/includes/js-interop/js-collocation.md @@ -142,6 +142,8 @@ The following `JsCollocation2` component's `OnAfterRenderAsync` method loads a J } ``` +In the preceding example, is trapped during module disposal in case Blazor's SignalR circuit is lost. If the preceding code is used in a Blazor WebAssembly app, there's no SignalR connection to lose, so you can remove the `try`-`catch` block and leave the line that disposes the module (`await module.DisposeAsync();`). For more information, see . + `{PATH}/JsCollocation2.razor.js`: ```javascript diff --git a/aspnetcore/blazor/includes/js-interop/synchronous-js-interop-call-js.md b/aspnetcore/blazor/includes/js-interop/synchronous-js-interop-call-js.md index 9e02f71e216c..98480a1163b4 100644 --- a/aspnetcore/blazor/includes/js-interop/synchronous-js-interop-call-js.md +++ b/aspnetcore/blazor/includes/js-interop/synchronous-js-interop-call-js.md @@ -47,14 +47,10 @@ When working with in ASP.NET Core { if (module is not null) { - try - { - await module.DisposeAsync(); - } - catch (JSDisconnectedException) - { - } + await module.DisposeAsync(); } } } ``` + +In the preceding example, a isn't trapped during module disposal because there's no Blazor-SignalR circuit in a Blazor WebAssembly app to lose. For more information, see . diff --git a/aspnetcore/blazor/javascript-interoperability/call-dotnet-from-javascript.md b/aspnetcore/blazor/javascript-interoperability/call-dotnet-from-javascript.md index 4824c1d35d83..40f26506f402 100644 --- a/aspnetcore/blazor/javascript-interoperability/call-dotnet-from-javascript.md +++ b/aspnetcore/blazor/javascript-interoperability/call-dotnet-from-javascript.md @@ -582,6 +582,7 @@ In the preceding example: * `JS` is an injected instance. is registered by the Blazor framework. * The variable name `dotNetHelper` is arbitrary and can be changed to any preferred name. * The component must explicitly dispose of the to permit garbage collection and prevent a memory leak. +* is trapped during module disposal in case Blazor's SignalR circuit is lost. If the preceding code is used in a Blazor WebAssembly app, there's no SignalR connection to lose, so you can remove the `try`-`catch` block and leave the line that disposes the module (`await module.DisposeAsync();`). For more information, see . `CallDotNetExampleOneHelper.razor.js`: diff --git a/aspnetcore/blazor/javascript-interoperability/index.md b/aspnetcore/blazor/javascript-interoperability/index.md index 543b4d2b76d4..a970d325670a 100644 --- a/aspnetcore/blazor/javascript-interoperability/index.md +++ b/aspnetcore/blazor/javascript-interoperability/index.md @@ -167,6 +167,8 @@ export function addHandlers() { } ``` +In the preceding example, is trapped during module disposal in case Blazor's SignalR circuit is lost. If the preceding code is used in a Blazor WebAssembly app, there's no SignalR connection to lose, so you can remove the `try`-`catch` block and leave the line that disposes the module (`await module.DisposeAsync();`). For more information, see . + For more information, see the following resources: * @@ -277,6 +279,8 @@ In the following example, the `DOMCleanup` component: } ``` +In the preceding example, is trapped during module disposal in case Blazor's SignalR circuit is lost. If the preceding code is used in a Blazor WebAssembly app, there's no SignalR connection to lose, so you can remove the `try`-`catch` block and leave the line that disposes the module (`await module.DisposeAsync();`). For more information, see . + In the following example, the `MutationObserver` callback is executed each time a DOM change occurs. Execute your cleanup code when the `if` statement confirms that the target element (`cleanupDiv`) was removed (`if (targetRemoved) { ... }`). It's important to disconnect and delete the `MutationObserver` to avoid a memory leak after your cleanup code executes. `DOMCleanup.razor.js` placed side-by-side with the preceding `DOMCleanup` component: diff --git a/aspnetcore/blazor/javascript-interoperability/location-of-javascript.md b/aspnetcore/blazor/javascript-interoperability/location-of-javascript.md index 14f3ec3d270c..74f95d165e0f 100644 --- a/aspnetcore/blazor/javascript-interoperability/location-of-javascript.md +++ b/aspnetcore/blazor/javascript-interoperability/location-of-javascript.md @@ -193,7 +193,7 @@ JS isolation provides the following benefits: * Imported JS no longer pollutes the global namespace. * Consumers of a library and components aren't required to import the related JS. -Trap in potential cases where loss of Blazor's SignalR circuit prevents a JS interop call from disposing a module, which results an unhandled exception. +In server-side scenarios, always trap in case loss of Blazor's SignalR circuit prevents a JS interop call from disposing a module, which results in an unhandled exception. Blazor WebAssembly apps don't use a SignalR connection during JS interop, so there's no need to trap in Blazor WebAssembly apps for module disposal. For more information, see the following resources: