I would strongly favor a declarative sync-based API for tracking server state on the client. I don’t know exactly how this would look (nor do I have a great understanding of Hologram’s existing APIs). But using Phoenix terminology, some way to specify that a given set of assigns should be automatically shipped to the client and kept up to date (with no tearing) would be a good path, I think.

I would not recommend venturing down the path of encouraging developers to maintain synchronization with their own imperative “glue” protocol (i.e. sending their own diffs down the wire by hand). This always ends badly.

Hi, @bartblast

I think of PubSub in Hologram the same way I think of events—they’re triggers (that sometimes carry data). These server-side “events” can be similarly bound to actions/commands, and the rest of the Hologram plumbing immediately becomes available to us. I imagine new server-side functions put_pubsub and delete_pubsub as the main additions.

Add a Subscription

To subscribe to a PubSub channel, call put_pubsub in init/3 or command/3:

put_pubsub(server, pubsub_channel, command: :my_command)

or

put_pubsub(server, pubsub_channel, action: :my_action)

Delete a Subscription

To unsubscribe from a PubSub channel, call delete_pubsub in command/3:

delete_pubsub(server, pubsub_channel)

or

delete_pubsub(server, pubsub_channel)

I suggest there should also be a cleanup mechanism that unsubscribes when a component is removed from the page.

To Handle a Message

Each time a pubsub message is received, its corresponding command/action is triggered and can be handled as such:

def command(:my_command, pubsub_msg, server) do
  # do something with the message
end

def action(:my_action, pubsub_msg, component) do
  # do something with the message
end

Additionally, I don’t think PubSub handling should be restricted to pages. This is one of the banes I have with LiveView where handle_info is available only in the LiveView and not in LiveComponents. Each component should be able to call put_pubsub and delete_pubsub in its own init/3 and command/3 functions.

Finally, I wouldn’t recommend adding a target option to put_pubsub where a subscription in one page/component can trigger a command or action in another. Each page/component should subscribe independently to a channel if it needs to react to messages. This is not a “hard” suggestion, but I think it will help avoid confusion.

PS: Thank you for always welcoming input from the community. We’re grateful for your hard work

Hi @jonas_h, thanks for the kind words and the nudge!

Short version: I’m no longer planning a dedicated PubSub API. The plan is now Local-First sync for data, plus Server-triggered actions for ephemeral events (notifications, presence, typing indicators, etc.).

Reasoning is in this reply from a few months back - short of it: PubSub for data sync forces you to wire up reconciliation by hand, which is exactly what leads to the bugs people keep running into. A declarative local-first layer handles that automatically. I also covered this in my recent ElixirConf talk - I’ll share the recording when it’s up.

Where things stand:

• Server-triggered actions are in progress and will ship in v0.9.0. Low-level primitive for ephemeral events, similar in spirit to PubSub - covers most realtime use cases.
• Local-First sync is still in the design phase (discussion here). The end goal is a declarative auto-sync store, so most apps won’t need the low-level primitive at all.

What you can do today: the linked reply also covers workarounds - polling-command + Hologram.JS.exec/1, Phoenix Channels alongside Hologram, etc. @ken-kost’s skribbl.io integration is likely along those lines - looking forward to his write-up.

Thanks for your patience, and glad you’re enjoying Hologram!