Overview - Router

7 days30 days

Latest CI Pipeline Executions

Fuzzy

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