Background
When <router-link> and the interceptor coexist, the interceptor's onInternalLink callback fires for router-link clicks in the capture phase. If the callback calls ctx.preventDefault() + router.push(), it works — but RouterLink-specific props like replace are silently ignored because the interceptor has no awareness of them.
Idea
In Vue 3, rendered DOM elements expose __vueParentComponent, which gives access to the component instance and its props. The Vue wrapper (packages/vue/src/plugin.ts) could use this to detect whether a clicked <a> was rendered by RouterLink and read its props:
const vnode = anchor.__vueParentComponent;
if (vnode?.type?.name === 'RouterLink') {
const isReplace = vnode.props?.replace;
// could expose this info to the callback via LinkContext
}This would allow the Vue wrapper to provide router-aware context without changing the framework-agnostic core.
Concerns
- Stability:
__vueParentComponent is a Vue internal API, not part of the public contract. It could change across Vue versions. (Vue DevTools relies on it, which gives some confidence, but it is still undocumented.)
- Cross-framework consistency: React and Svelte wrappers would need their own detection mechanisms (e.g. React Router
Link uses internal fiber nodes). Each framework has different internals, making a unified approach difficult.
- Scope: It is unclear how much RouterLink context is worth exposing.
replace is the main concern, but there are other props (activeClass, exactActiveClass, etc.) that are less relevant to interception.
Current status
Not blocking — RouterLink coexistence works correctly today. This is about improving DX for edge cases where RouterLink props affect navigation behavior.
Background
When
<router-link>and the interceptor coexist, the interceptor'sonInternalLinkcallback fires for router-link clicks in the capture phase. If the callback callsctx.preventDefault()+router.push(), it works — but RouterLink-specific props likereplaceare silently ignored because the interceptor has no awareness of them.Idea
In Vue 3, rendered DOM elements expose
__vueParentComponent, which gives access to the component instance and its props. The Vue wrapper (packages/vue/src/plugin.ts) could use this to detect whether a clicked<a>was rendered byRouterLinkand read its props:This would allow the Vue wrapper to provide router-aware context without changing the framework-agnostic core.
Concerns
__vueParentComponentis a Vue internal API, not part of the public contract. It could change across Vue versions. (Vue DevTools relies on it, which gives some confidence, but it is still undocumented.)Linkuses internal fiber nodes). Each framework has different internals, making a unified approach difficult.replaceis the main concern, but there are other props (activeClass,exactActiveClass, etc.) that are less relevant to interception.Current status
Not blocking — RouterLink coexistence works correctly today. This is about improving DX for edge cases where RouterLink props affect navigation behavior.