Blazor: Anchor Tree Item triggers full page navigation (doesn't support 'enhanced navigation')

[msmithNI]

🐛 Bug Report

When using NimbleAnchorTreeItem in a NimbleTreeView in a Blazor project, enhanced navigation (same-document navigation without a full navigate/ page reload) will not work. (NimbleAnchorTreeItem will always trigger a full navigate/ page reload, when activated.)

💻 Repro or Code Sample

BlazorAnchorTreeItemDemo.zip

See test project above. The Nimble Tree is at the top of the left pane, and navigating with that will trigger reloads (you'll see the nav pane flicker/refresh), whereas using the anchors/links further down will not reload.

🤔 Expected Behavior

NimbleAnchorTreeItem should support enhanced navigation (without full reload). Other controls like NimbleAnchor / NimbleAnchorButton do support that scenario already.

😯 Current Behavior

NimbleAnchorTreeItem triggers a full navigation/reload.

Workaround

Currently, if someone requires a Nimble tree + enhanced navigation, they can use NimbleTreeItem with registered onclick / onkeydown (for Enter key) handlers, which use the Blazor NavigationManager.NavigateTo() API to navigate.

Additional discussion

Blazor has page-level click interception logic to support enhanced navigation. See NavigationUtils in ASP.NET Core source, which no-ops if the click event had preventDefault() called. There's also EventDelegator.dispatchGlobalEventToAllElements which will stop going up the chain looking for an event target if stopPropagation happened.

The Nimble AnchorTreeItem clickHandler does stopPropagation, so that seems to cause the problem.

(To confirm, in DevTools if you unhook that event handler from the tree item at runtime, you do get the enhanced navigation behavior.)

[rajsite]

The Nimble AnchorTreeItem clickHandler does stopPropagation, so that seems to cause the problem.

It calls stopPropagation and the event handler returns true which opts-out of calling preventDefault (aside: returning true to opt-out of calling preventDefault is a very confusing api lol).

Stops the event propagation but not the navigation itself. Which does seem odd, if we want this normal "link like" thing to exist it should have a propagating click event a router can handle. Seems like tree view should be smarter about handling click events instead of trying to prevent the tree view from seeing the events.