Solid Router

Solid Router is the official routing library maintained by the SolidJS core team, bringing fine-grained reactivity to navigation so a single-page application can behave like a multi-page site without full reloads. Routes are declared either as JSX <Route> trees or as a plain object-based configuration, both compiled down to the same internal matcher, and the library ships four router integrations (Router, HashRouter, MemoryRouter, StaticRouter) covering standard browser history, hash-based navigation, in-memory testing, and server-side rendering.

Beyond path matching, Solid Router provides a full data layer: preload functions fetch data in parallel with route code-splitting following a render-as-you-fetch pattern, the query helper dedupes and caches async calls with a key-based reactive refetch mechanism, and createAsync turns any async function into a suspendable reactive primitive. Together with an action API for mutations and a complete set of navigation primitives (useParams, useNavigate, useLocation, useSearchParams, useMatch, and more), it functions as the routing and data-loading backbone that frameworks like SolidStart build on top of.

What You Get

• Four router integrations — history-based Router, HashRouter, MemoryRouter for tests, and StaticRouter for SSR — all built on one shared createRouter core
• JSX-based (<Route> component tree) or config-based (route definition array) route declaration, both compiling to the same matcher in src/routing.ts
• A preload hook per route that fetches data in parallel with lazy component loading, avoiding client-side request waterfalls
• A query API that dedupes in-flight requests, caches results for a rolling window, and reactively refetches by cache key on revalidation
• createAsync and action primitives that turn promises and mutations into Solid-reactive resources with automatic revalidation
• A complete navigation primitive set: useParams, useNavigate, useLocation, useSearchParams, useMatch, useCurrentMatches, useIsRouting, useBeforeLeave
• Automatic scroll restoration on back/forward navigation via src/routers/scrollRestoration.ts

Common Use Cases

• Converting a single-component SolidJS app into a route-based, code-split multi-page experience without full page reloads
• Server-rendered apps (including SolidStart) that need to preload page data on the server before first paint using StaticRouter plus preload/query
• Unit and integration tests that exercise routing logic, redirects, and param parsing in isolation using MemoryRouter instead of a real browser
• Apps embedded in a host page or served from a static file host that need HashRouter because path-based routing isn’t available
• Nested layouts with a persistent shell (navigation, sidebar) that stays mounted across route changes via a root component

Under The Hood

Architecture The routing core in src/routing.ts (728 lines) builds a route tree from either JSX <Route> composition or a plain config array and resolves it through a shared matcher (createMatcher, scoreRoute in src/utils.ts) that expands optional segments and wildcards. Router and route state propagate via Solid’s own createContext (RouterContextObj, RouteContextObj), with navigation tracked through createSignal/createMemo and applied in createRenderEffect — the reactive graph itself is the router, not a separate re-render pass layered on top of it. Four integrations (Router, HashRouter, MemoryRouter, StaticRouter in src/routers/) all delegate to one shared createRouter factory that swaps only the underlying history-source transport, keeping matching logic transport-agnostic. Data concerns (src/data/action.ts, createAsync.ts, query.ts, events.ts) live in a separate module layering a resource cache and revalidation-event bus on top of router context rather than being baked into the matcher.

Tech Stack Pure TypeScript against a solid-js peer dependency (^1.8.6), using isServer/getRequestEvent from solid-js/web for SSR detection. Built with tsc for type declarations and Rollup (@rollup/plugin-babel with babel-preset-solid, @rollup/plugin-terser) for bundling, published as ESM-only with conditional solid/default exports so consumers can receive either precompiled JSX or plain JS. The dev/test harness runs on Vite, vite-plugin-solid, Vitest, and jsdom, with pnpm workspaces and Changesets driving release automation.

Code Quality Thirteen Vitest spec files (router.spec.ts, route.spec.ts, integration.spec.ts, data.spec.tsx, lifecycle.spec.ts, routes-disposal.spec.tsx, scroll-restoration.spec.tsx, search-params.spec.tsx, utils.spec.ts, types.spec.ts, and others) cover routing, data, and lifecycle behavior, plus a dedicated test:types script that type-checks the test suite itself. CI runs the full test suite and separately verifies the published dist output’s type correctness with @arethetypeswrong/cli, catching ESM/type-export mismatches before release. Source is strict TypeScript with a centralized types.ts, formatted with Prettier, and mostly small single-purpose files apart from the necessarily dense routing.ts core.

API Design The public surface mirrors React Router’s <Router>/<Route> composition model, easing the mental-model jump for developers coming from other ecosystems, while unifying data loading behind one query() call that handles server-side dedup, client caching, and reactive refetch — avoiding the separate loader-plus-cache-library setup many frameworks require. preload attached directly to a route gives render-as-you-fetch without a separate data-router configuration layer, and there’s no required build-time route-generation step. Getting started needs only one <Router> wrapper, though effective use of query/action/createAsync together assumes familiarity with Solid’s own reactivity primitives first.