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.