Islands, Signals and Actions

Verniz sends useful HTML first, then hydrates only components marked @island. The client runtime attaches behavior to the existing DOM instead of rendering a second copy and comparing it.

A client-side island¶

use std::html::{div, button, span, View}

@island
fn Counter(start: int = 0) -> View {
    var<signal> count = start

    <div>
        <button onclick={ count -= 1 }>−</button>
        <span>{count}</span>
        <button onclick={ count += 1 }>+</button>
    </div>
}

var<signal> is writable source state. Each island instance gets its own state.

Derived state and effects¶

Use immutable signal storage for a value derived from other signals:

var<signal> price = 30
var<signal> quantity = 2
let<signal> total = price * quantity

effect(|| {
    document.title = "Total: {total}"
})

let<signal> cannot be assigned to; TE700 catches attempts to mutate derived state. Effects run in the browser and should be reserved for external state such as the document title, focus, logs or local storage.

DOM events, attributes and bindings¶

Use the DOM event name directly: onclick, ondblclick, onpointerdown, and so on. An attribute that reads a signal is recalculated when that signal changes.

<input bind:value={name} aria-label="Name"/>
<button disabled={name == ""}>Continue</button>
<input type="checkbox" bind:checked={accepted}/>

bind:prop names the DOM property explicitly, so value, checked, open and multiple bindings follow one rule.

Crossing back to the server¶

@action
fn greet(name: str) -> str {
    "Hello, {name}! From the server."
}

@island
fn Greeting() -> View {
    var<signal> name = ""
    var<signal> answer = ""

    <button onclick={ answer = greet(name) }>Send</button>
    <p>{answer}</p>
}

Only @action functions become remote endpoints. A call inside an island is compiled to an asynchronous request. The response can include a new document or fragment, and Verniz morphs it into the current DOM while preserving stable client state where identity is unambiguous.

Use key for identity when repeated content can move. Non-keyed reordering is intentionally conservative; a key is the contract that lets the runtime carry the right state to the right element.

Include the client runtime¶

Interactive pages need client_script() in the document head. The HTTP server supplies that script from /_zolo/client.js; there is no JavaScript bundler step.

The browser-only Verniz Lab supports local signals, derived state, effects, DOM events and bindings. It does not provide the HTTP endpoint required by @action.

Next: Scoped CSS.