nallwhy
I want to know socket connected user list on phoenix.
I used Presence and it works but it notifies all connection changes to all clients. I don’t want it.
The idea I have now is monitoring sockets with worker, but I want to know any better idea.
Thanks!
Trending in Questions
I’m working on a project that simulates the bumbl example in the programming phoenix book. It acts almost like an email client. We have a...
New
Hello,
I know there is an approach for handling lists that allows for optimized traversal, but I can’t recall the specific method (somet...
New
Hi everyone,
I am toying with the idea of building a “match maker” for giving personal help to people that wants to start coding.
I sta...
New
Documentation
While reading the Scoped Routes section, I noticed that the documentation currently refers to a problem without explainin...
New
So my question is quite simple and i have found no conclusive answer on forum, google or AI.
Should we use :erlang.float for Integer to ...
New
I recently noticed that Elixir’s Logger defaults its primary log level to :debug when no :logger, :level application configuration is pre...
New
apply_graft/2 doesn’t rewrite an add_many sub-workflow’s deps on an add step. Grafted jobs cancel with “upstream job was deleted”
Version...
New
Other Trending Topics
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Hi there! We created Gust: A task orchestrator inspired by Airflow.
For those who have never heard about Aiflow, it’s a Python-based wor...
New
Hi everyone!
The first release candidate for the Expert language server project is now available!
We’ve published a press release detai...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex










Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
Track all the users in Presence under a key different to the channel name. This will prevent users from receiving the diff messages.
nallwhy
cool! thx!
rjk
I had another method found earlier within this forum and that is to
intercept(["presence_diff"])inside the channel module. That’s the message phoenix tries to send to provide the presence to connected clients. By intercepting you are able the change the outgoing message (even changing it to a no-op and effectively not sending a message to the clients).To change the presence_diff message you use the following in the same channel module (where you just added the intercept line from above):
def handle_out("presence_diff", _, socket), do: {:noreply, socket}Because this function returns a noreply it will not send out any presence information to the connected clients.
I guess both methods work but maybe this method conveys your intention a little better.
LostKobrakai
It surely does convey the intention quite well, but not trying to send diffs in the first place is probably the better implementation than trying to send them just to discard them on their way. I’m not sure how performance intensive a noop intercept is, but it has a warning that customizing messages per user can become a performance issue.
If you track users in presence using e.g. something like an
internal:userstopic I feel like the intend can be communicated in a similarly explicit fashion.rogerweb
Maybe I’m doing something wrong but no matter the key I use (e.g.:
internal:users), Presence still sends thepresence_diffmessage to all users.This is Phoenix 1.6.10.
LostKobrakai
Are you sure the topic chosen is not one covered by a channel?
rogerweb
I would say so. This is the rest of my
user_channel.exfile:LostKobrakai
You’re not changing the topic here. When you use
track/3it’strack(socket, key, metadata). You wanttrack/4astrack(pid, topic, key, metadata).rogerweb
That was it. I was taking the term key in your comments literally, when I should have thought about it as the topic.
Thanks a lot @LostKobrakai. It is working now.
LostKobrakai
I’ve edited my post, so hopefully you’re the last one to fall for that.