hono-preact
Overview
Quick Start
The Route Table
Layouts & Nesting
Adding Pages
Active Links
Server Loaders
Loading States
Reloading Data
Prefetching
Streaming
Live Loaders
Realtime Channels
Server Actions
Validation
Optimistic UI
View Transitions
Middleware
CSRF Protection
CLI
Vite Config
Project Structure
Composing Hono Middleware
WebSockets
Rooms & Presence
renderPage
Link Prefetch
Build & Deploy
Overview
Dialog
Popover
Tooltip
Menu
Context Menu
Select
Combobox
Toast
renderElement
useControllableState
mergeRefs
useListNavigation
useTypeahead
useListboxSelection
usePosition
usePositioner
useDismiss
useFocusReturn
useSafeArea
usePresence

Prefetching Data#

prefetch runs a loader and fills its cache ahead of navigation, so the destination route renders immediately when the user arrives. Use it when you can predict the user's next move (hover on a link, scroll into view, idle after page load) and the loader is non-trivial.

Basic usage#

import { prefetch } from 'hono-preact';
import { serverLoaders } from './pages/movie.server.js';

const movieLoader = serverLoaders.default;

// On link hover, kick off a fetch for /movies/42 so the route is ready when clicked.
function onMovieLinkHover(id: number) {
  prefetch(movieLoader, { url: `/movies/${id}`, route: '/movies/:id' });
}

The result is written into the loader's cache (when one is configured) and the next navigation reads from cache instead of refetching.

Common patterns#

Hover prefetch is the typical case: bind to onMouseEnter on a link and call prefetch with the destination URL.

Idle prefetch is useful for the next-most-likely route. Call prefetch from a requestIdleCallback after the current page settles.

Programmatic prefetch works anywhere: a router transition listener, a search-as-you-type debounce, an intersection observer for cards scrolling into view.

prefetch checks the loader's cache first and returns immediately when the destination is already warm. A hover handler firing repeatedly (mouse over → off → back over the same link), an intersection observer re-entering visibility, or duplicate idle-callback scheduling will not issue redundant network requests. The cache key combines path with whatever searchParams the loader's params option declares, so two prefetches for /movies/41 and /movies/42 each hit the network exactly once.

Why pass url and route?#

Loaders receive a RouteHook location ({ path, searchParams, pathParams }). When your loader reads location.pathParams.id or location.searchParams.q, prefetching with no location would crash or return the wrong data. Pass the URL the user is about to navigate to, plus the route pattern, and prefetch derives a complete RouteHook for you:

  • url populates path (trailing slash stripped, root preserved) and searchParams.
  • route is the matching route pattern (e.g. /movies/:id); when present, pathParams is derived by matching url against it.

If you don't read any of those fields, omit both arguments and prefetch(loader) still works.

Options#

OptionTypeDescription
urlstringTarget URL or path. Drives path and searchParams.
routestringRoute pattern (e.g. /movies/:id). Combined with url to derive pathParams.
locationRouteHookEscape hatch: pass a fully-formed RouteHook directly. Overrides url/route.
cacheLoaderCache<T>Override the cache the result is written to. Defaults to the cache attached to the loader.

See also#