Live HTML · In depth

LivePage and start

Pages are plain decorated classes; extending LivePage is optional. Prefer defineApp({ pages: [...] }) and app.run() for startup. start() remains a supported lower-level convenience.

Explain it like I’m five

The simple mental model

A page class describes one server-owned screen. defineApp groups the screens and socket routes; run opens their shared front door.

When it fits

When should I use it?

Use a plain @page class for route-owned state, actions and rendering. LivePage inheritance and start remain compatibility options, not requirements.

A practical API pattern

Follow the example

This pattern explains the named API. Application classes, credentials, and assets may need to be supplied; use a complete recipe for a runnable starting point.

Read this article as Markdown

TSX

import { action, defineApp, page, state } from 'redweb';

@page('/', { shared: true })
class CounterPage {
    @state() count = 0;

    @action()
    increment() { this.count += 1; }

    render() {
        return <button rw-click="increment">Count {this.count}</button>;
    }
}

const app = defineApp({ pages: [CounterPage] });
app.run();

1
@page declares the HTTP route and page policy.
2
@state reads in TSX update automatically; no output wrapper or repeated binding name is required.
3
defineApp registers the page, and app.run starts it. The example uses shared state deliberately so two tabs see the same counter.

Surface area

Methods and members

start(PageClass, options?)

Starts one decorated page, or an array of pages, with the concise Live HTML server API.

loading(context)

Optional cancellable hook that runs before the initial server render.

connected(context)

Optional hook that runs after the authenticated live socket connects.

disconnected(context)

Optional hook for stopping connection-owned timers and subscriptions.

disposed()

Optional idempotent final cleanup hook for pages and components.