[OnurGumus]

Builds on #88 (Fable.Lit.Server). Until that merges, this PR also shows its commit. Only the last commit is new here.

The browser half of server rendering: adopting the markup Fable.Lit.Server writes, for plain templates and for Elmish programs.

// a template
Hydrate.adopt (document.getElementById "items") (Views.table items)

// an Elmish program
Program.mkProgram init update view
|> Program.withLitHydrated "app"
|> Program.run

Hydrate.adopt

Adopts markup written by renderHydratable in place, through @lit-labs/ssr-client's hydrate: the elements stay, and lit attaches its bindings to them. After that, Lit.render on the same container updates it as usual.

What it adds over calling hydrate directly is the fallback. Without it, a refusal from lit is a broken page:

• lit throws on a template mismatch, part way through wiring the container. adopt catches it, logs a warning to the console, clears the container and renders the view. The clearing matters: lit's render inserts beside what's already there, so rendering over the refused markup would show the page twice.
• A container with no markers at all is refused without a throw. lit logs to the console and hydrate returns as if it had worked, leaving the container empty. adopt notices the missing root part and renders instead.

Different data isn't caught, by lit or here. I checked what happens: the server renders count 0 and the browser adopts with 5. The page shows 0, a render with 5 still shows 0 (lit believes 5 is already there), and only a change to 6 updates it. The docs say so.

Program.withLitHydrated / withLitHydratedOnElement

Mounts an Elmish program whose first render adopts instead of rendering. Every render after that is an ordinary one. The first model must be the one the server rendered from.

One dependency question

Hydrate.fs imports @lit-labs/ssr-client at module level, and Lit.Elmish refers to Hydrate. So a bundler has to resolve @lit-labs/ssr-client for every Lit.Elmish app, even one that never hydrates. Fable.Lit declares it in NpmDependencies, so it shows up as a dependency rather than as "Rollup failed to resolve import". With tree-shaking, nothing from it ends up in the bundle unless adopt is called.

If you'd rather Lit.Elmish didn't carry that, the Elmish functions could move to a separate file or package. It's a trade-off I'd leave to you.

Sample

sample/Hydrate: an ASP.NET server renders a page with Fable.Lit.Server, and the client adopts it with Hydrate.adopt. Both projects are in the solution, so CI builds them. I ran it as the README says: the button works, the table row and the button are the same DOM nodes after two clicks (patched, not rebuilt), a <script> in the data shows up escaped as text, and there's no fallback warning. Its vite config now resolves paths from its own folder; written relative to the current directory, the README's command failed from the repo root.

Tests

Three browser tests in DifferentialTest.fs, over markup from the .NET tests:

• a refused adoption leaves one copy of the page, not two;
• an empty container gets the view rendered, and its handler works;
• an Elmish program over server markup keeps the server's button, handles a click, and patches the DOM rather than rebuilding it.

Each fails when the code it covers is taken out:

• without the clearing, the first fails;
• without the missing-marker check, the second;
• with the first Elmish render made a plain render, the third.

dotnet build Fable.Lit.sln, dotnet test test/Lit.Server.Tests (23) and npm test (44) pass locally in CI's order. The "Server rendering" docs page now covers Hydrate.adopt and the Elmish functions.

🤖 Generated with Claude Code