3: Broadcasting with wsCast

wsCast is how a handler pushes to clients. It posts a message to the broker, which fans it out to the targeted sockets, and each browser applies it through the same phlo.js apply pipeline your async routes already use.

3.1: Targets

wsCast(wsTarget: 'all', inner: ['#online' => (string)$count])
wsCast(wsTarget: $wsSocket, toast: 'Just for you')

• wsTarget: 'all' broadcasts to every connected socket.
• wsTarget: $wsSocket sends to one socket.
• Token-scoped targeting lets you reach every socket for a given user.

Everything after the target is an ordinary apply instruction: inner, outer, prepend, append, toast, scroll, and so on. The client treats a cast exactly like the response to a form, so the same view-update code works for both transports.

3.2: wsCast can fail; guard it

wsCast makes an HTTP call to the broker. If the broker is not running, it throws. Wrap it so the rest of your handler (and your plain async path) keeps working:

function cast(...$args){
    try {
        wsCast(...$args)
    }
    catch (\Throwable $e){
    }
}

This guard is what makes a phloWS app degrade cleanly to a non-realtime app when the broker is down.

3.3: The browser client

Loading the DOM/websocket resource ships a small client. It opens a socket only when the page body has the class wss, reconnects automatically, and applies incoming casts. To turn realtime on for a page, put the app in that mode (the demo sets prop options = 'wss'); leave it off and the same page is a normal Phlo page.