What you are building
A page whose initial number comes from a request to Rust. Open ?count=17 and the HTML already contains 17 before any browser script runs. This lesson is about rendering request data; the number is in the URL, not saved in a database.
One declared contract
TypeScript describes the page and declares a count prop. The compiler turns the supported page structure into FMIR, the representation Rust uses to render HTML. Rust derives a matching PageProps schema, binds the page and finalizes the route set before listening. Each request supplies its own count.
Your exercise
- Enter 17 in the form and choose Render from Rust. A new document opens at the demo with 17 as its initial server value.
- Open the raw response link: find 17 in the HTML. The link makes another request with the same count; it does not capture later browser clicks.
- Disable JavaScript and submit 23. Rust still returns HTML containing 23. Refresh keeps 23 because it is now in the URL.
This proves useful HTML comes from the server. It does not prove data was saved: a different URL can ask Rust to render a different number.
To add JSON APIs, middleware, database access or calls to external services, continue with the application backend guide.
What the server actually does
let response = page.render(&DemoProps { count }, &RenderCtx::new())?;
// Return the complete PageResponse through IntoResponse.This is the call boundary, not a complete server. The runnable lab’s source includes asset loading, typed binding, route verification, finalization, request validation and error handling.
The native compiler admits a defined TSX subset. It does not execute arbitrary JavaScript in Rust, and unsupported source is a coded build error. Compute application logic in your Rust handler and pass presentation props.
Response policy is part of the response
Keep the generated HTML, fresh CSP nonce and no-store policy together. Don’t take the body from a native response and cache it independently of its headers.