Router: event listener on internal links is overly broad

[egardner]

Describe the bug

We are using Vitepress to power a documentation and demo site for a UI library (https://doc.wikimedia.org/codex/main/), as an alternative to Storybook.

Recently I created a new page to demonstrate a tabbed layout component, which makes use of some internal links (with @click.prevent applied) for semantic/accessibility purposes. I was surprised to see that the demo page contained some unanticipated behavior – clicking a tab caused the page to jump around and updated the URL with a fragment ID.

This is happening because the Vitepress router introduces a global event listener for all internal link elements on the page, adding some extra behavior (updating the URL hash, scrolling the target element into view). This makes sense for heading or section elements on the page, but it's being applied everywhere.

Is there any way to scope this to be a little more specific? Maybe this handler should only apply to headings or section elements, or should only target elements that have been created by Vitepress as part of the page theme?

Reproduction

Behavior can be seen here: https://772516--wikimedia-codex.netlify.app/components/tabs.html – click a tab in one of the demo components and watch the page jump around.

Expected behavior

Not expecting additional behavior to be added to links inside embedded demo components on pages.

System Info

System:
    OS: macOS 12.3
    CPU: (10) arm64 Apple M1 Pro
    Memory: 141.38 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.14.0 - /opt/homebrew/opt/node@16/bin/node
    npm: 8.3.1 - /opt/homebrew/opt/node@16/bin/npm
  Browsers:
    Chrome: 99.0.4844.83
    Firefox: 98.0.1
    Safari: 15.4

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.

[kiaking]

Not sure how to tackle this issue yet, but we should consider it before 1.0.0 release since this might cause breaking changes on how links work.

[brc-dd]

@kiaking Should we introduce a new attribute data-no-click? If it is not present on an anchor or its parents, only then run that logic. This way OP can specify click events on which components should not be handled by the router's event handler.

[kiaking]

Hmmm... This issue is a little related to #199, where this is about CSS but it's kinda same in a way that it would be great to have a "scoping" feature in the doc theme.

In that sense, maybe it might be better to introduce a block element or custom component for this...? Something like:

<Raw>
 <MyComponent />
</Raw>

And we ignore everything inside <Raw> component (if that's possible 🤔).

And to do that, I think adding data-no-click attribute as a first step sounds nice idea 👍

[jd-solanki]

Using Raw component is definitely a nice solution but I have my input here.

Like @egardner (and me 😄), there will be cases where VitePress will get used for component demo, and adding Raw component on each page 3-4 times is not a good DX.

Sorry, I don't have a solution to share this at the moment.

[brc-dd]

So here is my solution (workaround) for CSS isolation: #199 (comment)

We probably should just check for .vp-raw instead of data-no-click. And document this😅. We can have that postcss thing built in VP too.