Repository navigation
Issue disposing a component's JS complement in a Blazor Web App using mixed render modes #62230
Description
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
Activity
javiercn commentedon Jun 4, 2025
@pkostaki thanks for contacting us.
The documentation sample might be a bit simplistic. You can use the
subtreeoption as an alternative tochildListto 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,
MutationObserveris meant to be a high performance to previous approaches likeDOMNodeInsertedandDOMNodeRemoved.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
enhancednavigationstartandenhancednavigationendJS events to run any logic when a navigation happens and perform any necessary cleanup.pkostaki commentedon Jun 4, 2025
@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.
Let me check the usage of
enhancednavigationstartandenhancednavigationend(I’ll get back with the results)Thanks!
javiercn commentedon Jun 5, 2025
@pkostaki fair enough.
I'm going to move this to the backlog for consideration in a future release.
pkostaki commentedon Jun 5, 2025
Utilizing navigation enhancement-related events with the JS initializer, I’ve handled the case. Thank you for the information.