dreamland's SSR implementation is based around DOM element construction order, so it is especially prone to hydration errors with differing logic on server vs client.
The server-side API is based around domhandler's DOM with a custom internal DOM that implements the bare minimum needed for dreamland.
This internal DOM is exposed to components on the server-side when rendering to SSR.
dreamland provides a Vite plugin to enable SSR on the dev server for easy setup:
render from dreamland/ssr/server to render the common file's export into domhandler elementshydrate from dreamland/ssr/client to hydrate the common file's export. This is your new client entrypoint.<!--ssr-head--> and <!--ssr-body--> to your html entrypoint, with ssr-body replacing the existing app root and ssr-head wherever you want to keep the SSR data.devSsr plugin to your vite.config.ts, configuring the server entrypoint with the entry key.You can use SSR in production builds as well by telling vite to build a SSR bundle with --ssr and the server entrypoint, importing your render function from that bundle, and using the renderSsr helper from dreamland/vite to render the page like the dev server does.
dreamland's router is strictly a layer above the dreamland core and SSR, so prerendering simply means telling your own code to route to a different path and saving that to a different file. You can check out this docs site's code (in the dreamland repo's site folder) for a working SSR + prerendering example.