Render the Lustre Server Component client runtime. The content of your server component will be rendered inside this element.

Note: you must include the lustre-server-component.mjs script found in the priv/ directory of the Lustre package in your project’s HTML or using the script function.

Ocassionally you may want to attach custom data to an event sent to the server. This could be used to include a hash of the current build to detect if the event was sent from a stale client.

Your event decoders can access this data by decoding data property of the event object.

The server component client runtime sends JSON encoded actions for the server runtime to execute. Because your own WebSocket server sits between the two parts of the runtime, you need to decode these actions and pass them to the server runtime yourself.

Instruct any connected clients to emit a DOM event with the given name and data. This lets your server component communicate to frontend the same way any other HTML elements do: you might emit a "change" event when some part of the server component’s state changes, for example.

This is a real DOM event and any JavaScript on the page can attach an event listener to the server component element and listen for these events.

Encode a DOM patch as JSON you can send to the client runtime to apply. Whenever the server runtime re-renders, all subscribed clients will receive a patch message they must forward to the client runtime.

Properties of a JavaScript event object are typically not serialisable. This means if we want to pass them to the server we need to copy them into a new object first.

This attribute tells Lustre what properties to include. Properties can come from nested objects by using dot notation. For example, you could include the id of the target element by passing ["target.id"].

import gleam/dynamic
import gleam/result.{try}
import lustre/element.{type Element}
import lustre/element/html
import lustre/event
import lustre/server

pub fn custom_button(on_click: fn(String) -> msg) -> Element(msg) {
  let handler = fn(event) {
    use target <- try(dynamic.field("target", dynamic.dynamic)(event))
    use id <- try(dynamic.field("id", dynamic.string)(target))

    Ok(on_click(id))
  }

  html.button([event.on_click(handler), server.include(["target.id"])], [
    element.text("Click me!")
  ])
}

The route attribute tells the client runtime what route it should use to set up the WebSocket connection to the server. Whenever this attribute is changed (by a clientside Lustre app, for example), the client runtime will destroy the current connection and set up a new one.

Inline the Lustre Server Component client runtime as a script tag.

On the Erlang target, Lustre’s server component runtime is an OTP actor that can be communicated with using the standard process API and the Subject returned when starting the server component.

Sometimes, you might want to hand a different Subject to a process to restrict the type of messages it can send or to distinguish messages from different sources from one another. The select effect creates a fresh Subject each time it is run. By returning a Selector you can teach the Lustre server component runtime how to listen to messages from this Subject.

The select effect also gives you the dispatch function passed to effect.from. This is useful in case you want to store the provided Subject in your model for later use. For example you may subscribe to a pubsub service and later use that same Subject to unsubscribe.

Note: This effect does nothing on the JavaScript runtime, where Subjects and Selectors don’t exist, and is the equivalent of returning effect.none().

A server component broadcasts patches to be applied to the DOM to any connected clients. This action is used to add a new client to a running server component.

Remove a registered renderer from a server component. If no renderer with the given id is found, this action has no effect.