Skip to content

PubSub integration for LiveViews and LiveComponents - #4441

Draft
SteffenDE wants to merge 7 commits into
mainfrom
sd-pubsub-sender
Draft

SteffenDE wants to merge 7 commits into
mainfrom
sd-pubsub-sender

Conversation

@SteffenDE

@SteffenDE SteffenDE commented Sep 11, 2026

Copy link
Copy Markdown
Member

Comment thread mix.exs
Comment on lines +53 to +54
{:phoenix_pubsub,
github: "phoenixframework/phoenix_pubsub", branch: "sd-sender", override: true},

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: replace with release
TODO: should we allow older versions and conditionally compile it?

Comment thread lib/phoenix_live_view/channel.ex Outdated
Comment thread lib/phoenix_live_view/channel.ex Outdated
Comment thread lib/phoenix_live_view.ex
Comment thread lib/phoenix_live_view/pubsub.ex Outdated
# we use the process dicationary so to prevent cases where a user calls
# subscribe in assign_async or a custom Task, we check and raise
# if this process is not demonstrably a LiveView
case Process.get(:"$process_label") do

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we are using the process dictionary for subscriptions, we can use the process dictionary itself to detect if we are inside a LiveView?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All we need to do is to initialize it to an empty map.

def unsubscribe_cid(cid) do
for {{pubsub, topic}, {_ref, subscribers}} <- pubsub_subscriptions(),
Map.has_key?(subscribers, cid) do
do_unsubscribe(pubsub, topic, cid)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should have a cid => topics mapping....


%{} ->
# we might still have stale messages in the mailbox
# so we ignore those silently

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the scenario I mentioned in the call today. We don't need to worry about it, we already handle it. However, we could use Process.aliases if we want to reduce the amount of stale messages (they can still exist but sometimes they won't be sent).

Comment thread lib/phoenix_live_view.ex
pubsub :: module(),
topic :: binary(),
callback :: (message :: term(), socket :: Socket.t() -> Socket.t())
) :: Socket.t()

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am wondering if we should return the socket. I am thinking we should not and instead return :ok or whatever. Otherwise, someone may have the impression that, if you call subscribe but ignore the socket, nothing happens. Returning :ok makes it clearer it is a side-effect.

We should also document that you want to avoid closing over the state in the anonymous function and always use &handle_foo_bar/2 format. Perhaps an admonition block.

Comment thread lib/phoenix_live_view.ex
"""
@spec subscribe(
socket :: Socket.t(),
pubsub :: module(),

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we make the pubsub an optional argument?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants