{ "webjs": { "clientRouter": false } }
data-no-router
/logout
data-preserve-scroll
${topic ? '?topic=' + topic : '(default, no ?topic=)'}
Mutating form submissions (POST / PUT / PATCH / DELETE) clear the cache automatically on success. You only need revalidate() when the mutation happens via JS / RPC and didn't go through a form.
revalidate()
A forward navigation scrolls to the top, the way a browser does. data-preserve-scroll is the per-link escape hatch, for a navigation that changes only part of what the reader is looking at: a filter, sort, or tab link whose control sits below the fold, a pager, or a form that re-renders in place with validation errors. WebJs wants it more than most frameworks do, because a searchParams-only navigation already morphs the deepest shared boundary and keeps the hydrated state of every component around it, so the scroll is the only thing such a navigation still throws away.
The attribute resolves through closest(), so one mark on a wrapping element covers every link inside it, and data-preserve-scroll="false" on something nearer opts back out. On a form the lookup starts at the submitter and falls back to the form, so a marked form covers its buttons even when one is attached from elsewhere with form="id" rather than nested inside it. A hash link still scrolls to its anchor, because the reader named a target and a named target beats a blanket preference. It is inert on a frame-targeted link, since a frame swap never writes a scroll to begin with, and inert with JS off, where the link is a plain <a>, so nothing about a page's correctness may depend on it.
closest()
data-preserve-scroll="false"
form="id"
<a>
It carries the reader's current offset onto the destination. It does not restore the offset they once had there, which is a different feature and not one WebJs ships, so this is the wrong tool for a "back to the list" link.
Same-origin in-app links are prefetched speculatively, so a click resolves from a warm cache with no round-trip. No attribute is needed; it is on for every internal <a href>, the way Next, Nuxt, and SvelteKit ship auto-prefetch, and the prefetch sends the same headers a real navigation does so the click consumes the fragment.
<a href>
The default strategy is device-adaptive, because one strategy cannot serve both input modalities. On a hover-capable pointer (mouse / trackpad) the default is intent (warm on hover or focus, a real head-start before the click). On touch the default is viewport (warm as links settle on-screen), because touch has no hover and touchstart fires at tap time, too late to help. The modality is detected with matchMedia('(hover: hover) and (pointer: fine)'), not a user-agent sniff, and a per-link data-prefetch always overrides it.
touchstart
matchMedia('(hover: hover) and (pointer: fine)')
data-prefetch
refreshPage() re-renders the current URL on the server and applies it in place, with no page load. It records no history entry and never scrolls, so the reader keeps their place and Back still goes to the previous page.
refreshPage()
To keep the router but skip its scroll-to-top, the attribute is data-preserve-scroll rather than this one. See Preserving scroll on a forward navigation above.
'use client'
WebComponent
@click
'use server'
.server.{js,ts}
useState
useEffect
signal
computed
@webjsdev/core
connectedCallback
updated
next/link
<Link scroll={false}>
next/image
<img>
width
height
loading="lazy"
getServerSideProps
getStaticProps
export default async function Page({ params, searchParams, url })
.server
generateStaticParams
export const revalidate = N