Skip to content

Commit 75b820f

Browse files
authored
JS interop/circuit disposal updates (#34178)
1 parent 2fe0292 commit 75b820f

File tree

5 files changed

+11
-8
lines changed

5 files changed

+11
-8
lines changed

aspnetcore/blazor/includes/js-interop/js-collocation.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -142,6 +142,8 @@ The following `JsCollocation2` component's `OnAfterRenderAsync` method loads a J
142142
}
143143
```
144144

145+
In the preceding example, <xref:Microsoft.JSInterop.JSDisconnectedException> 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 <xref:blazor/js-interop/index#javascript-interop-calls-without-a-circuit>.
146+
145147
`{PATH}/JsCollocation2.razor.js`:
146148

147149
```javascript

aspnetcore/blazor/includes/js-interop/synchronous-js-interop-call-js.md

Lines changed: 3 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -47,14 +47,10 @@ When working with <xref:Microsoft.JSInterop.IJSObjectReference> in ASP.NET Core
4747
{
4848
if (module is not null)
4949
{
50-
try
51-
{
52-
await module.DisposeAsync();
53-
}
54-
catch (JSDisconnectedException)
55-
{
56-
}
50+
await module.DisposeAsync();
5751
}
5852
}
5953
}
6054
```
55+
56+
In the preceding example, a <xref:Microsoft.JSInterop.JSDisconnectedException> isn't trapped during module disposal because there's no Blazor-SignalR circuit in a Blazor WebAssembly app to lose. For more information, see <xref:blazor/js-interop/index#javascript-interop-calls-without-a-circuit>.

aspnetcore/blazor/javascript-interoperability/call-dotnet-from-javascript.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -582,6 +582,7 @@ In the preceding example:
582582
* `JS` is an injected <xref:Microsoft.JSInterop.IJSRuntime> instance. <xref:Microsoft.JSInterop.IJSRuntime> is registered by the Blazor framework.
583583
* The variable name `dotNetHelper` is arbitrary and can be changed to any preferred name.
584584
* The component must explicitly dispose of the <xref:Microsoft.JSInterop.DotNetObjectReference> to permit garbage collection and prevent a memory leak.
585+
* <xref:Microsoft.JSInterop.JSDisconnectedException> 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 <xref:blazor/js-interop/index#javascript-interop-calls-without-a-circuit>.
585586

586587
`CallDotNetExampleOneHelper.razor.js`:
587588

aspnetcore/blazor/javascript-interoperability/index.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -167,6 +167,8 @@ export function addHandlers() {
167167
}
168168
```
169169

170+
In the preceding example, <xref:Microsoft.JSInterop.JSDisconnectedException> 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 <xref:blazor/js-interop/index#javascript-interop-calls-without-a-circuit>.
171+
170172
For more information, see the following resources:
171173

172174
* <xref:blazor/js-interop/javascript-location>
@@ -277,6 +279,8 @@ In the following example, the `DOMCleanup` component:
277279
}
278280
```
279281

282+
In the preceding example, <xref:Microsoft.JSInterop.JSDisconnectedException> 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 <xref:blazor/js-interop/index#javascript-interop-calls-without-a-circuit>.
283+
280284
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.
281285

282286
`DOMCleanup.razor.js` placed side-by-side with the preceding `DOMCleanup` component:

aspnetcore/blazor/javascript-interoperability/location-of-javascript.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -193,7 +193,7 @@ JS isolation provides the following benefits:
193193
* Imported JS no longer pollutes the global namespace.
194194
* Consumers of a library and components aren't required to import the related JS.
195195

196-
Trap <xref:Microsoft.JSInterop.JSDisconnectedException> in potential cases where loss of Blazor's SignalR circuit prevents a JS interop call from disposing a module, which results an unhandled exception.
196+
In server-side scenarios, always trap <xref:Microsoft.JSInterop.JSDisconnectedException> 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 <xref:Microsoft.JSInterop.JSDisconnectedException> in Blazor WebAssembly apps for module disposal.
197197

198198
For more information, see the following resources:
199199

0 commit comments

Comments
 (0)