Replies: 2 comments 1 reply
-
|
Here's the |
Beta Was this translation helpful? Give feedback.
-
To be honest, I didn't expect people would use
Yes, I think it's reasonable if we allow using |
Beta Was this translation helpful? Give feedback.
-
|
I think you would reproduce the prefetch issue if you start on waku.gg/blog and enable OK. I'll submit a PR for review. Thanks. |
Beta Was this translation helpful? Give feedback.
-
I think the we should probably skip prefetch and refetch by default if the hash is the only part of the route that has been updated. Here are some snippets of what we might change in the Link component:
Thoughts? I can't think of a reason to make another server request if only the hash changes.
My use case is a sidebar with hash navigation for multiple pages. I want preloading if I'm jumping to a different page but I don't want to make unnecessary server requests.
If the pathname has not changed, Waku attempts to find a matching element by ID and uses 'auto' scroll behavior to scroll to it. If I add
className="scroll-smooth"to my root<html>element, it smooth scrolls to the element which is nice.If we don't want to change the default behavior for refetch, then maybe we can add a skipRefetch prop to the Link component? That would allow us to have logic for that prop to decide whether to refetch.
I noticed that it doesn't work to scroll to a matched hash element if the path has changed. It always scrolls to the top even if the url has a hash. I added my own hook to listen for hash changes from
useRouter(). I don't know if it makes sense for Waku to add something to catch that use case. My hook has to poll for the element to be loaded on the page.It seems that the path and hash update in useRouter() before the server has started streaming the new page response. If it's an dynamic server request that hasn't been prefetched, it should probably wait for a server response before updating the route props.
Beta Was this translation helpful? Give feedback.
All reactions