SSR / foldkit-ssr

Why you would use it

Foldkit already renders on the server. What its page carries is the input: the Flags that produced the first Model, which the browser decodes and feeds to init again. That is simple and right when init is cheap and its Flags are small.

It stops being right when init does real work: it loads a post, reads a session, computes something expensive. Then the browser either repeats that work or has to receive everything init read, as Flags, including data the page never shows. foldkit-ssr sends the result instead: the fields the browser owns, and nothing else.

Foldkit's own (renderToString + Runtime.hydrate)foldkit-ssr (SSR.render + SSR.hydrate)
The page carriesThe FlagsThe plan's slice of the Model; no Flags
init runsOn the server, then again in the browserOn the server only
Server-only dataCrosses if init needs itStays on the server unless the slice includes it
A view that reads unsent stateRebuilt in the browser; only development warnsRefused by SSR.render, naming the field, before it is served
What you writeNothing beyond the configA plan

Beyond the handover it offers three things you can adopt one at a time: server-owned static regions that never render in the browser, resumable pages that answer clicks and typing before the runtime has booted, and forms that work with scripts off, answered by running update on the server.

What it owns, and what it does not

It owns the handover: which slice crosses, how it is written into the page, and the checks that the browser can start from it.

  • Rendering and adoption stay Foldkit's. SSR.render calls Foldkit's renderToString and SSR.hydrate calls Runtime.hydrate. Foldkit still refuses a page from another build and still adopts the server's nodes.
  • The Model stays the application's. A plan names fields of it; it adds no state of its own, and every change after boot goes through update.
  • Data belongs to its package. Remote's store crosses through Remote's own part (Remote.resume), which decides what to capture.