Overview - Router

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Failed
8192
Fix ready→
de72ade3 feat(solid-router): loadFlightTarget, the cache-agnostic single-flight trigger The router's half of flight collection as a public primitive: derive the flight request for the mutation's target, run the matched routes' data functions, hand the loaded router to the caller's collect() — any cache (the router's own state, a query client) composes its extraction on top. Start's collector now consumes it; errors are contained per Solid Router's collector convention (flight data is an optimization, never a mutation error). Co-authored-by: Cursor <cursoragent@cursor.com>
by Ryan Carniato
Succeeded
8193
74435de2 refactor(solid): retire solid-router-ssr-query — Solid's native channels carry the Router + Query pairing solid-query v6's QueryClientProvider serializes the request's cache into Solid's hydration registry during SSR and primes the client cache from it, so running the ssr-query transport alongside it ships every query payload twice. The package's two runtime conveniences are each a few lines of userland composition on public APIs: the provider wrap via the router's Wrap option, and cache-driven redirect() errors handed to router.navigate from the caches' config.onError. Converts the three Solid Start e2e apps to the composition (all suites green, including the redirect-from-query tests) and marks the package deprecated for the v2 line. Co-authored-by: Cursor <cursoragent@cursor.com>
by Ryan Carniato
Succeeded
solid-router-v2-pre
41cffa00 fix(solid-router): make the global loading boundary opt-in and server/client-symmetric (#8027) * fix(solid-router): make the global loading boundary opt-in and server/client-symmetric `Matches` wrapped the match tree in a client-only `Solid.Loading` boundary unless `disableGlobalCatchBoundary`, `isServer`, or `router.ssr` was set, while the server side always rendered `SafeFragment`. Apps that server-render without the `$_TSR` stream protocol (own server entry: memory history, awaited `router.load()`, `renderToStream`) never set `router.ssr`, so the client hydrated a boundary the server never rendered. That desyncs Solid's positional node claiming and surfaces as an opaque `reconcileArrays` crash (`NotFoundError: insertBefore`). The wrapper is now opt-in and the decision is evaluated identically on the server and the client. It renders only when all of these hold: - the app configured root pending UI (root `pendingComponent` or `defaultPendingComponent`) — new; - `router.ssr` is not set (the `$_TSR` protocol short-circuit, unchanged and pinned by tests); - `disableGlobalCatchBoundary` is not set (unchanged). There is no `isServer` arm, no hydration probe, and no match-state inspection — the decision reads only router configuration, so the server tree and the hydrating client tree cannot disagree. With nothing configured there is no wrapper at all: pending propagates as ordinary Solid 2 async. The previous behavior there was an invisible `Solid.Loading` with a `null` fallback, which also converted errors to pending. With pending UI configured, the boundary now renders on both sides, so external SSR hydrates cleanly (server nodes claimed and reused, no pending flash) and the pending UI keeps working for post-hydration navigations — a client-only wrapper, even a settled one, shifts hydration-key derivation and leaves the server nodes unclaimed. Tests: matches-hydration-boundary.test.tsx pins the opt-in decision, the protocol short-circuit, `disableGlobalCatchBoundary`, and that the decision is identical whether or not a hydration pass is in flight (a hydration-keyed decision would freeze `SafeFragment` into hydrated apps permanently); server-mode matchesLoadingBoundary.test.tsx pins the symmetric server output. Verified additionally against a real `renderToString` -> `hydrate` round trip: zero hydration errors, zero unclaimed nodes, server DOM reused by identity. Co-authored-by: Cursor <cursoragent@cursor.com> * ci: apply automated fixes --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
by Ryan Carniato
Succeeded
8027
0059ba3f fix(solid-router): make the global loading boundary opt-in and server/client-symmetric `Matches` wrapped the match tree in a client-only `Solid.Loading` boundary unless `disableGlobalCatchBoundary`, `isServer`, or `router.ssr` was set, while the server side always rendered `SafeFragment`. Apps that server-render without the `$_TSR` stream protocol (own server entry: memory history, awaited `router.load()`, `renderToStream`) never set `router.ssr`, so the client hydrated a boundary the server never rendered. That desyncs Solid's positional node claiming and surfaces as an opaque `reconcileArrays` crash (`NotFoundError: insertBefore`). The wrapper is now opt-in and the decision is evaluated identically on the server and the client. It renders only when all of these hold: - the app configured root pending UI (root `pendingComponent` or `defaultPendingComponent`) — new; - `router.ssr` is not set (the `$_TSR` protocol short-circuit, unchanged and pinned by tests); - `disableGlobalCatchBoundary` is not set (unchanged). There is no `isServer` arm, no hydration probe, and no match-state inspection — the decision reads only router configuration, so the server tree and the hydrating client tree cannot disagree. With nothing configured there is no wrapper at all: pending propagates as ordinary Solid 2 async. The previous behavior there was an invisible `Solid.Loading` with a `null` fallback, which also converted errors to pending. With pending UI configured, the boundary now renders on both sides, so external SSR hydrates cleanly (server nodes claimed and reused, no pending flash) and the pending UI keeps working for post-hydration navigations — a client-only wrapper, even a settled one, shifts hydration-key derivation and leaves the server nodes unclaimed. Tests: matches-hydration-boundary.test.tsx pins the opt-in decision, the protocol short-circuit, `disableGlobalCatchBoundary`, and that the decision is identical whether or not a hydration pass is in flight (a hydration-keyed decision would freeze `SafeFragment` into hydrated apps permanently); server-mode matchesLoadingBoundary.test.tsx pins the symmetric server output. Verified additionally against a real `renderToString` -> `hydrate` round trip: zero hydration errors, zero unclaimed nodes, server DOM reused by identity. Co-authored-by: Cursor <cursoragent@cursor.com>
by Ryan Carniato
Succeeded
8027
0059ba3f fix(solid-router): make the global loading boundary opt-in and server/client-symmetric `Matches` wrapped the match tree in a client-only `Solid.Loading` boundary unless `disableGlobalCatchBoundary`, `isServer`, or `router.ssr` was set, while the server side always rendered `SafeFragment`. Apps that server-render without the `$_TSR` stream protocol (own server entry: memory history, awaited `router.load()`, `renderToStream`) never set `router.ssr`, so the client hydrated a boundary the server never rendered. That desyncs Solid's positional node claiming and surfaces as an opaque `reconcileArrays` crash (`NotFoundError: insertBefore`). The wrapper is now opt-in and the decision is evaluated identically on the server and the client. It renders only when all of these hold: - the app configured root pending UI (root `pendingComponent` or `defaultPendingComponent`) — new; - `router.ssr` is not set (the `$_TSR` protocol short-circuit, unchanged and pinned by tests); - `disableGlobalCatchBoundary` is not set (unchanged). There is no `isServer` arm, no hydration probe, and no match-state inspection — the decision reads only router configuration, so the server tree and the hydrating client tree cannot disagree. With nothing configured there is no wrapper at all: pending propagates as ordinary Solid 2 async. The previous behavior there was an invisible `Solid.Loading` with a `null` fallback, which also converted errors to pending. With pending UI configured, the boundary now renders on both sides, so external SSR hydrates cleanly (server nodes claimed and reused, no pending flash) and the pending UI keeps working for post-hydration navigations — a client-only wrapper, even a settled one, shifts hydration-key derivation and leaves the server nodes unclaimed. Tests: matches-hydration-boundary.test.tsx pins the opt-in decision, the protocol short-circuit, `disableGlobalCatchBoundary`, and that the decision is identical whether or not a hydration pass is in flight (a hydration-keyed decision would freeze `SafeFragment` into hydrated apps permanently); server-mode matchesLoadingBoundary.test.tsx pins the symmetric server output. Verified additionally against a real `renderToString` -> `hydrate` round trip: zero hydration errors, zero unclaimed nodes, server DOM reused by identity. Co-authored-by: Cursor <cursoragent@cursor.com>
by Ryan Carniato