<Link> renders a plain <a> server-side, so it works with JavaScript off, on slow links, and during the brief moment before hydration completes. Once Pylon’s runtime is live, clicks get intercepted and Pylon does a client-side navigation instead of a full page reload.
What it does
The React root persists across navigations, so any layout that’s shared between the old and new route keeps its instance. State, scroll position, video playback — all survive the nav.
API
className, target, rel, onClick, etc.) passes through.
Examples
Basic
Disable prefetch for off-screen links
A large paginated list with a “next page” link the user might never click:Open in a new tab
Programmatic navigation
<Link> is the prop-based API. For imperative nav (after a form submit, post-login redirect, etc.), call the global runtime:
window.__pylon is defined as soon as hydration completes. Use the ?. form to be safe on the first render. (Pylon has no RSC boundary, so there’s no "use client" directive — every page component already hydrates on the client.)
How nav actually works
- User clicks a
<Link>. The runtime’s delegated handler picks it offa[data-pylon-link]clicks. - Runtime fetches the target URL with the standard
Accept: text/htmlheader. The server SSRs the new page just like a direct navigation would. - Runtime parses the response and extracts the
__PYLON_DATA__JSON tag (component name, layouts, props). - Runtime looks up the new component in the bundle manifest and dynamically imports its entry chunk.
- The entry chunk’s
hydrate(component, Page, Layouts)populates the route cache without re-rendering (the cache is keyed on component path). - Runtime calls
root.render(buildTree(Page, Layouts, newProps)). React’s reconciler diffs against the existing tree — shared layouts get reused, the page subtree swaps. history.pushState, scroll to top, done.
window.location.href = href so the browser handles it the old-fashioned way.
Differences from Next.js’s <Link>
The hash-link +
scroll props are on the roadmap.