mirror of
https://github.com/Dvorinka/Devour.git
synced 2026-06-04 04:23:02 +00:00
Tomas Dvorak
17 lines
3.6 KiB
JSON
17 lines
3.6 KiB
JSON
{
|
|
"id": "709daf5c603c9a004d761d2b",
|
|
"source": "solid:signals",
|
|
"type": "github-document",
|
|
"title": "preloading",
|
|
"content": "---\ntitle: Preloading\n---\n\nPreloading smooths navigation by resolving route code and data before a user completes a transition.\nSolid Router listens for intent signals, such as hover and focus, and primes the matching route after a short delay to balance responsiveness and network cost.\nUnderstanding the timing and scope of this work lets you decide when to rely on the default behaviour and when to layer custom strategies.\n\n| user action | route behaviour |\n| ----------- | --------------- |\n| hover | waits roughly 20 ms before preloading |\n| focus | preloads immediately |\n\n## How Solid Router Detects Intent\n\nAnchors registered with Solid Router emit hover and focus events that feed a small scheduler.\nThe router debounces the hover signal for 20ms to ignore incidental pointer passes while still reacting quickly to purposeful movement.\nWhen the delay elapses, the router loads the route module and runs its preload routine so that navigation has the assets it needs when the user commits.\n\nRoute modules can export a [`preload`](/solid-router/reference/preload-functions/preload) function that receives params, search values, and router context.\nThe function lets you seed caches, warm derived computations, or coordinate streaming behaviours without blocking the eventual render.\n\n\u003e [!NOTE]\n\u003e SSR invokes route `preload` functions during the initial server render and resumes them on the client during hydration.\n\u003e Keep these functions pure so the hydrated client does not need to undo server work when it takes over.\n\n## Imperative Preloading Hooks\n\nNot every interaction funnels through an anchor element.\nThe [`usePreloadRoute`](/solid-router/reference/primitives/use-preload-route) primitive exposes the same scheduling behaviour for imperative flows like flyout previews, timers, or observer driven experiences.\n\nThis helper mirrors the router behaviour by resolving the module, optionally running the loader, and caching the result for the eventual navigation.\nEmpirical tuning of delay values helps you avoid excessive prefetching in dense UIs while still keeping high intent interactions snappy.\n\n## Coordinating Nested Lazy Components\n\nNested lazy components live outside the router hierarchy, so route preloading does not automatically warm them.\nThe component API [`lazy()`](/reference/component-apis/lazy) exposes a `preload()` method that resolves a component without rendering it.\nCalling both the route preload and the nested component preload can keep large detail panels responsive when a user hovers or focuses on the entry point.\n\nBalancing manual preloading requires observing real user flows so you avoid prefetching large bundles that the user never requests.\nProfiling tools help you spot whether preloading reduces long tasks or simply shifts work earlier without net gains.\n\nTo learn more about lazy loading components, see the [lazy documentation](/reference/component-apis/lazy#preloading-data-in-nested-lazy-components).",
|
|
"url": "https://github.com/solidjs/solid-docs/blob/HEAD/src/routes/solid-router/advanced-concepts/preloading.mdx",
|
|
"metadata": {
|
|
"path": "src/routes/solid-router/advanced-concepts/preloading.mdx",
|
|
"repo": "solidjs/solid-docs",
|
|
"repo_url": "https://github.com/solidjs/solid-docs.git",
|
|
"size": 2960,
|
|
"source_type": "github"
|
|
},
|
|
"hash": "a2d21ad9c7cf17cb9ab7aecd5b2a4e9d7628968bded174a11d8cf11dc3084a5f",
|
|
"timestamp": "2026-02-23T11:43:00.191484563+01:00"
|
|
} |