Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 #2995fix: update
sveltekit:prefetch
mouse detection #2995Changes from 6 commits
88658f1
3274e0e
47b8696
f058fca
3419386
26d6bcd
f06924d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
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?There was a problem hiding this comment.
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.There was a problem hiding this comment.
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.There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 checkingparentNode
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 thecomposedPath
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......then whether or not the
<a>
will be included in thecomposedPath
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.
There was a problem hiding this comment.
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.There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!