Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: update sveltekit:prefetch mouse detection #2995

Merged
merged 7 commits into from Dec 22, 2021
Merged
Show file tree
Hide file tree
Changes from 6 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
5 changes: 5 additions & 0 deletions .changeset/lazy-ways-swim.md
@@ -0,0 +1,5 @@
---
'@sveltejs/kit': patch
---

fix `sveltekit:prefetch` mouse detection
8 changes: 6 additions & 2 deletions packages/kit/src/runtime/client/router.js
Expand Up @@ -94,7 +94,7 @@ export class Router {
}, 200);
});

/** @param {MouseEvent|TouchEvent} event */
/** @param {Event} event */
const trigger_prefetch = (event) => {
const a = find_anchor(event);
if (a && a.href && a.hasAttribute('sveltekit:prefetch')) {
Expand All @@ -109,12 +109,16 @@ export class Router {
const handle_mousemove = (event) => {
clearTimeout(mousemove_timeout);
mousemove_timeout = setTimeout(() => {
trigger_prefetch(event);
// ensure event.composedPath() in find_anchor(event) returns an array of EventTarget objects
borntofrappe marked this conversation as resolved.
Show resolved Hide resolved
event.target?.dispatchEvent(
new CustomEvent('sveltekit:trigger_prefetch', { bubbles: true })
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if something like sveltekit:mousestop might be a better name for this? What do you guys think?

Copy link
Member

@bluwy bluwy Dec 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either works for me, but it does looks nicer when used in the addEventListener call below.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I lean toward sveltekit:trigger_prefetch as well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My instinct is to look for an alternative solution altogether — it seems weird to dispatch a custom event just to indirectly call our own function, no?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I realised there's a deeper problem here. The composedPath stuff was introduced because recursively checking parentNode to find an <a> element doesn't work if the <a> in question is in shadow DOM.

The solution here dispatches a custom event on e.target, but the composedPath of the custom event won't include the shadow <a> in certain cases. Demo here — basically, if you have a custom element with an <a> in the shadow DOM like this...

customElements.define(
  'fancy-a',
  class extends HTMLElement {
    constructor() {
      super();

      let a = document.createElement('a');
      a.href = this.getAttribute('href');
      a.innerHTML = '<slot></slot>';

      let shadowRoot = this.attachShadow({ mode: 'open' });
      shadowRoot.append(a);
    }
  }
);

...then whether or not the <a> will be included in the composedPath depends on whether the original event happened to happen within an element in light DOM inside the custom element.

I'm not exactly sure how to solve this, or if it's even possible. We might have to just say that prefetching won't work with shadow DOM.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That does look a bit risky and potentially more resource intensive. I wonder if it would be fine to not support sveltekit:prefetch in web components at all, the usecase would be rare. And also that normal link clicks should already work in web components.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would be totally fine dropping support for prefetch with web components

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm on the pragmatic side here. I don't think that dispatching a custom element with an explanation why this is needed is bad nor does it clutter the code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem dispatching event is that Rich showed it doesn't work all the times with custom elements. I share the sentiment from @bluwy that the issue is becoming rather cumbersome.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very well, if we're okay only having partial support for shadow DOM then we can merge this — thanks. Very annoying that the existence of shadow DOM forces us to jump through these ridiculous hoops in the first place!

);
}, 20);
};

addEventListener('touchstart', trigger_prefetch);
addEventListener('mousemove', handle_mousemove);
addEventListener('sveltekit:trigger_prefetch', trigger_prefetch);

/** @param {MouseEvent} event */
addEventListener('click', (event) => {
Expand Down