This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-10-29
Channels
- # announcements (1)
- # aws (4)
- # beginners (45)
- # biff (4)
- # calva (13)
- # clojure (38)
- # clojure-europe (2)
- # clojure-nl (1)
- # clojure-norway (2)
- # clojure-sweden (8)
- # clojurescript (9)
- # conjure (1)
- # core-async (4)
- # fulcro (5)
- # graalvm (6)
- # gratitude (3)
- # hyperfiddle (10)
- # off-topic (40)
- # pathom (4)
- # portal (23)
- # releases (1)
- # xtdb (5)
In photon, is there a way to run code on the server when the websocket connection breaks? E.g. if the browser tab is closed? My use case is keeping a set of connected clients in an atom on the server and I need to update the list when a client leaves
The current photon entrypoint does not expose the underlying websocket lifecycle. We are thinking about this use case.
In the meantime, you can detect a photon program being stopped (because the websocket connexion is gone) by catching missionary.Cancelled
at the program root (just after p/boot).
Also you can have a look at the jetty adapter in the photon codebase.
Thank you. Yes, I looked at the adapter and it was just logging the close event so I hoped there was a way from photon. I was experimenting with catching Cancelled and didn't get it working but it sounds like I'm thinking along the right lines there at least.
we are going to discuss on monday - can you tell us more context about the business user story you are trying to accomplish?
I'm making a multiplayer game with chat and I'd like to implement presence (just a list of connected users). So a user can enter a name to join, I add the name in an atom on the server and all clients can see who is in the chat. This works fine, but I need to remove names from the set when they leave the page or have some way to check if a client is still connected to update the list
This is what the answer is supposed to look like. However this triggers a known bug in our network layer which causes the detection of the disconnected tab to be arbitrarily delayed until the next message is received. The root cause is related to how lazy sampling of signals interacts with the eager network layer. We understand the fix, we've been delaying the implementation because it's non-trivial and has not been a priority
The above code works subject to the constraint that if bob closes his tab, his presence won't be removed until someone sends a packet to the server (i.e. by alice sending another chat message, or really any state change that causes a "reactive if" to switch and thereby send a message to the server)
Does this constraint work for you in the meantime?