live

Loom Live

Live templates need a persistent bidirectional channel between the browser and server to push UI updates in response to user events. This module implements a multiplexed WebSocket handler that routes multiple live components over a single connection, tagging each message with a component ID so the server dispatches to the correct actor.

Types

EventMessage

</>

An event message targets a specific component by id and carries the handler name, event type, and special variables.

pub type EventMessage {
  EventMessage(id: String, event: loom.ClientEvent)
}

Constructors

EventMessage(id: String, event: loom.ClientEvent)

JoinMessage

</>

The client sends a join message to register a new live component on the multiplexed connection. The id is assigned by the client, the module identifies the template, and the token carries signed initial props.

pub type JoinMessage {
  JoinMessage(id: String, module: String, token: String)
}

Constructors

JoinMessage(id: String, module: String, token: String)

LeaveMessage

</>

A leave message tells the server to stop the actor for the given component id.

pub type LeaveMessage {
  LeaveMessage(id: String)
}

Constructors

```
LeaveMessage(id: String)
```

WsState

</>

A single WebSocket connection multiplexes multiple live components. Each component’s actor is stored in a dict keyed by the client-assigned component ID. The shared reply_subject receives messages from all actors; the id field in each message identifies which component it belongs to.

pub type WsState {
  WsState(
    actors: dict.Dict(String, process.Subject(loom.SocketMessage)),
    reply_subject: process.Subject(loom.SocketMessage),
  )
}

Constructors

WsState(
  actors: dict.Dict(String, process.Subject(loom.SocketMessage)),
  reply_subject: process.Subject(loom.SocketMessage),
)

Values

upgrade

</>

pub fn upgrade(
  request: request.Request(mist.Connection),
) -> response.Response(mist.ResponseData)

The router calls this to hand off an HTTP request to the WebSocket subsystem. Wiring up on_init, on_close, and handle_message here keeps the connection lifecycle in one place while delegating state management to the live_socket actors.

verify_init_token

</>

pub fn verify_init_token(
  token: String,
  module_name: String,
  app_key: String,
) -> Result(String, Nil)

Verifies a signed init token and extracts the props JSON. The token contains module_name:props_json signed with the app key. Verification ensures the signature is valid and the embedded module name matches the claimed module, preventing token reuse across modules or tampered props.