Server-component navigation PoC

Evidence report for the second Server Component experiment. Recorded 2026-09-26 on branch feat/server-component-navigation-poc, baseline 1d7293a (main, merge of PR #23). Written by hand; pnpm test:server-component-navigation reproduces every observation below.

Path note (2026-09-28). StrataIslandHost now lives in the private @strata-sc/server-components package, which writes no globals. The window.__STRATA_ISLAND_PROBE__ counters described below moved to the fixture's src/probes/server-components/probe.ts (provideIslandProbe()), next to provideNavigationProbe(),, which counts the island host views attached to the ApplicationRef and their destruction. The results below are as recorded.

Question. Can a route containing a Strata Server Component take part in navigation without shipping the server component implementation to the browser? Two mechanisms are compared: a full document navigation, and an Angular Router client-side navigation.

Verdict: CONDITIONAL GO.

initial SSR (direct load)       ✓
document navigation             ✓   GO
Angular Router navigation       ✗   NO-GO: no supported seam

Document navigation to a server-component route behaves exactly like a direct load. The server renders a new document, the island hydrates onto the server nodes, and nothing server-only reaches the browser. An Angular Router navigation to the same route completes without any error and renders the generated surrogate. The surrogate is an empty <product-details></product-details>. There is no server request, no server subtree and no island. Angular 22, Analog 2.7 and Vite 8 offer no public seam that lets a client transition obtain a server-rendered subtree and hydrate it. The overall GO is conditional on server-component routes being reached by document navigation only.

No packages/* change was made, and no API was published.

Exact tuple

Unchanged from the graph PoC: @angular/* 22.1.7, @analogjs/* 2.7.2, Nitro 2.13 (node-server), Vite 8.3.0, TypeScript 6.0.3, Playwright 1.62.1 (Chromium). The Analog fixture's production build is used throughout.

Current graph model (from PR #23, unchanged)

@ServerComponent() module
  ssr/Nitro graph    → real component + ProductRepository + server-secret
  client graph       → generated surrogate: same selector, template "", StrataIslandHost
                       + client references (AddToCartComponent)
initial document     → SSR HTML with ngh annotations → surrogate hydrates without claiming
                       the server children → StrataIslandHost hydrates each [data-strata-client]
                       as its own root (createComponent({ hostElement }))

The surrogate has nothing to render on the client. Every server-rendered node it carries comes from the document that bootstrapped the application.

What was added

The two counters are separate globals on purpose. A first version shared one probe.ts module between the app entry and the lazy page chunk. Rolldown then split Angular into three shared chunks (4 → 6 client files, +3 KB). Keeping islands.ts self-contained restores the PR #23 chunk layout: 4 client chunks, one @angular/core copy, PoC − control = +2,280 B.

How the two navigations are told apart

A changed URL proves nothing, so every flow records three independent signals:

1. JavaScript realm sentinel. Before the click the runner sets window.__STRATA_NAVIGATION_SENTINEL__. A new document loses it. A client navigation keeps it.
2. Navigation Timing. performance.getEntriesByType("navigation")[0] names the document that is currently alive, and how it was loaded (navigate, back_forward).
3. Network. Every request carries the phase it was issued in, together with its resource type, its isNavigationRequest() flag, and whether its response body contains server-rendered product data (Product 42).

The router probe adds a fourth signal: its event log restarts in a new document.

Direct-load baseline (regression)

GET /server-component, as in PR #23. pnpm test:server-components still passes all 36 checks: the control leak, the absence of browser markers, the server markers, SSR, hydration by DOM identity and the click. The navigation runner repeats the essentials:

Document navigation: GO

/server-component-navigation (fresh, hydrated) → click Document navigation.

Network during the navigation: the destination document (carrying the server-rendered product), then index-*.js, index.page-*.js and server-component.page-*.js. These are the same scripts as a direct load.

Back (page.goBack()): the origin was reloaded as a new document (sentinel absent, entry back_forward). Headless Chromium did not restore it from the back/forward cache here. The origin is shown, and no product-details, add-to-cart or product text is left. There are no errors.

Re-entry (origin → destination → origin → destination): the second arrival is again a new realm (/server-component (navigate)). It holds exactly one hydrated island (created: 1 in that document). The count is Count: 0 on entry, and two clicks give Count: 1, then Count: 2: one handler, one increment per click. The whole flow logs no console errors, warnings or page errors.

Angular Router navigation: NO-GO (measured, not assumed)

A fresh /server-component-navigation, with the sentinel set → click Router navigation.

The resulting DOM (production build):

<app-root ng-version="22.1.7" ng-server-context="ssr-analog"
  ><router-outlet></router-outlet
  ><app-server-component-page
    ><main><product-details></product-details></main>
    <nav>
      <a routerlink="/server-component-navigation" href="/server-component-navigation"
        >Leave (router)</a
      >
    </nav></app-server-component-page
  ><!----></app-root
>

Network during the router navigation (the complete list):

GET script /assets/server-component.page-<hash>.js

• Did Angular only download the client route chunk? Yes: one request, the lazy route chunk.
• Did it call Nitro/the server for data or HTML? No. There was no fetch or XHR. The only request went to the static /assets/ file that Nitro serves.
• Did it perform a document request? No.
• Did any server-rendered payload arrive? No. No response contained Product 42.

On Back (popstate, handled by the router in the same realm) the origin is shown and <product-details> is removed. On router re-entry the host is the same empty one, with still no island. The route chunk is already loaded, so no request is made at all.

The PR #23 limitation is therefore confirmed and pinned by the test. It is not a defect of the graph PoC. It is the navigation gap this experiment set out to measure.

DOM lifecycle and island destruction

A direct load of /server-component (island hydrated, click → Count: 1), then a click on Leave (router), then Router navigation back:

When the route is left, Angular destroys the surrogate. Its DestroyRef.onDestroy destroys the island ComponentRef (attached to ApplicationRef with attachView), so no view is orphaned. The server-rendered nodes are removed along with the surrogate's host element. No errors were logged. The router cannot bring the subtree back, because the application has no copy of it.

Public seams investigated

The question asked of each one: can a client router transition obtain a server-rendered route subtree and have Angular integrate (hydrate) it, without the server component's implementation in the browser graph?

Unsupported / private seams (recorded, not built on)

• NGH_DATA_KEY / __nghData__, retrieveHydrationInfo, enableRetrieveHydrationInfoImpl and cleanupDehydratedViews are Angular internals (unprefixed inside the FESM chunks but absent from the public typings). They would be needed to hydrate a second server payload.
• IS_HYDRATION_DOM_REUSE_ENABLED and PRESERVE_HOST_CONTENT are private tokens.
• Analog's deferStreamingPlugin patches @angular/core strings (applyDeferBlockState, collectNativeNodesInLContainer). That is renderer patching.
• Any fetch → innerHTML/DOMParser/replaceChildren insertion followed by a hydration attempt. It would only show that HTML can be copied into the DOM (excluded by the brief).

None of these is imported or used by authored code.

Candidate strategy attempted

None. No public seam passed the question above, so no SPA candidate was built. Every remaining route would need a private hydration key, DOM injection, or a patched renderer. Each is excluded, and none would show a viable integration. The brief also allowed an isolated micro-experiment, but it was not needed: the limitation is fully explained by the public API surface and the installed sources.

Graph leak result

Scripts actually loaded, across all flows: index-*.js, index.page-*.js, server-component.page-*.js, server-component-navigation.page-*.js. Router navigation downloads the same surrogate chunk, and nothing else.

Classification

Document navigation:  GO
Router navigation:    NO-GO   (no supported seam; empty surrogate, silent)
Overall:              CONDITIONAL GO

initial SSR          ✓
document navigation  ✓
SPA navigation       ✗

The overall GO holds under these conditions:

1. Server-component routes must be entered by document navigation. Today nothing enforces it. A routerLink to such a route "succeeds" (NavigationEnd, no error) and shows an empty component. That silent failure is the main hazard this experiment found.
2. The conditions of the graph PoC verdict still apply (unspecified hydration behaviours, a non-portable build transform, islands as separate roots).
3. Leaving a server-component route through the router is fine: islands are destroyed and no views are orphaned. Coming back through the router is not.

Limitations

• Chromium only, through Playwright, on the Node node-server preset. Workers were not attempted.
• Back/forward cache: headless Chromium reloaded the origin on Back. A real browser may restore it (or the destination) from the bfcache instead. Both are whole documents, but a bfcache restore of the destination was not observed.
• One server component, one island, one route, one navigation shape. There are no nested routes, parameters, prefetching or query changes.
• The router probe and island counters are fixture evidence, not a lifecycle API.

Recommended next step (not implemented)

Make the measured constraint structural: the build should know which routes contain a server component, and fail (or warn) when a routerLink/Router.navigate target resolves to one of those routes, so they are only reached by document navigation. The silent empty surrogate would then become a build-time error. Nothing here designs that mechanism.

Reproduce

pnpm test:server-component-navigation

The command does a production build, then graph scans, then starts the production Nitro server. It runs the direct-load regression in Chromium, then the document navigation flow (with Back and re-entry), then the router characterization (with Back and re-entry), then the island teardown flow, and finally the runtime script scan. It exits non-zero on any failed check, including a router result that differs from the recorded limitation. It runs in CI after pnpm test:server-components.