Issue disposing a component's JS complement in a Blazor Web App using mixed render modes

[pkostaki]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

There is no reliable way for disposing a component's JS complement in a Blazor Web App using mixed render modes.

Additionally, the documentation confirms this behavior: DOM cleanup tasks during component disposal, suggesting the use of a MutationObserver on the component’s parent HTML element. However, this approach fails in scenarios where a higher-level ancestor (e.g., the parent of the parent) is removed. Using a MutationObserver on the entire document to catch such removals is inefficient.

Calling dispose JS method from the .NET side (during component disposal) to JavaScript doesn't work in apps with mixed render modes — the element mappings are cleared when navigating from a page with one render mode to another with a different render mode. ( ⚠ with Blazor Server or Blazor WebAssembly apps there is no such issue).

Please, check the attached sample.

Expected Behavior

component's element mapping is retained until its .NET side is disposed.

Steps To Reproduce

Run sample: BlazorMixedRenderModeIssueWebApp.zip

• navigate to Counter page
• navigate to Weather page

Exceptions (if any)

.NET Version

9.0.300

Anything else?

No response

[javiercn]

@pkostaki thanks for contacting us.

The documentation sample might be a bit simplistic. You can use the subtree option as an alternative to childList to observe changes on the entire DOM tree and take action.

You can attach the mutation observer to the parent node of any root component, and you should always receive a callback whenever a give node changes.

As for efficiency, MutationObserver is meant to be a high performance to previous approaches like DOMNodeInserted and DOMNodeRemoved.

If you are looking to handle cases where the component switch from one render mode to another or is gone from the page, you can use the enhancednavigationstart and enhancednavigationend JS events to run any logic when a navigation happens and perform any necessary cleanup.

[pkostaki]

@javiercn , thank you for response.

Sure, in my own application, I definitely know the closest parent of the component to use when initiating a MutationObserver.

However, for a component in an RCL (as in the current case), which will be used by others, there's no way to know which closest parent in the chain up to the document root should be used to initiate the MutationObserver.

The only reliable way is to use the document root itself, like:
new MutationObserver(...).observe(document, ...)
However, in this case, reacting to every document update would be an unnecessary performance overhead.

If you are looking to handle cases where the component switch from one render mode to another or is gone from the page, you can use the enhancednavigationstart and enhancednavigationend JS events to run any logic when a navigation happens and perform any necessary cleanup.

Let me check the usage of enhancednavigationstart and enhancednavigationend (I’ll get back with the results)

Thanks!

[javiercn]

@pkostaki fair enough.

I'm going to move this to the backlog for consideration in a future release.

[pkostaki]

Utilizing navigation enhancement-related events with the JS initializer, I’ve handled the case. Thank you for the information.