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

Thanks everyone! I love how we’ve accidentally created a buffet of real-time patterns

If I understood correctly:

• @Eiji proposed process messaging (very Elixir-native!)
• @garrison proposed state sync (declarative and clean)
• @jam proposed reactive queries (ambitious and exciting - I’d definitely like to explore the local-first path you showcased! I have something similar in mind for next stages)

All fascinating approaches, but I should clarify - I’m specifically looking for Pub/Sub (Publish/Subscribe) patterns. Think broadcasting messages across channels/topics like Phoenix Channels and Phoenix PubSub, but reimagined for ideal DX.

The exciting part: Hologram could eventually work across clusters of devices (web/mobile/desktop), so we could target specific users, sessions, or even component IDs (cids). We could broadcast to “all users in room X,” “session Y,” or “component Z on any device.”. Eventually… For now let’s just make it work for common cases.

Forget implementation details or what Phoenix did - what would the ideal developer experience look like for publishing/subscribing to messages across this kind of distributed component system?

Let’s get creative!

I trust your ideas will be great, since the DX for hologram in general feels great. My use case would be your example of svg drawing from 0.5.0 release - I want to broadcast changes to other players in the room. I’m making a scribble game in your framework - it’s fun! This is my missing piece.

I would say that at least for now you should go the “safe way” and implement Pub/Sub that is very similar to the phoenix one. Of course some framework-related things have to be adjusted (actions vs handle_* functions), but I would rather stay with similar naming concept simply to make migrating existing applications to Hologram as simple as possible.

I think that’s fastest way, best for initial adoption and does not block possible alternative solutions in future. Maybe a good point would be to release it as hologram_pubsub, so it’s not considered as a part of the core and could be easily replaced only by updating generators (if any) and guides.