This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (1)
- # beginners (39)
- # boot (14)
- # cider (2)
- # clara (6)
- # cljs-dev (39)
- # cljsrn (2)
- # clojure (276)
- # clojure-italy (1)
- # clojure-russia (22)
- # clojure-sg (2)
- # clojure-spec (7)
- # clojure-uk (9)
- # clojurescript (47)
- # core-async (1)
- # cursive (5)
- # emacs (1)
- # events (3)
- # leiningen (1)
- # luminus (2)
- # lumo (75)
- # om (14)
- # onyx (1)
- # parinfer (11)
- # pedestal (1)
- # ring-swagger (2)
- # spacemacs (4)
- # untangled (5)
- # yada (29)
I’m returning a core async channel to yada for SSE, does anyone know if I can register a callback for when the client closes the connection?
Closing the connection will cause the channel to close. You can wait on that using alts. Presumably you're using a tap or sub?
Manifold is my preference too. Since this week's yada release manifold streams can be returned from response bodies. Try with
You’ve definitely lost me with
periodically. I’ve got some state associated with an open SSE connection, and I want to know when I can discard it. I had hoped that I could perform this action
manifold.stream/on-closed, but the stream never seems to be closed.
@peterwestmacott fwiw I've tested that
on-closed works as a notification when the client closes the channel
The one thing I noticed is that
ms/periodically can only be used as a manifold source so you cannot call
on-closed on it.
However, you can connect it with a normal buffered stream to achieve the requirement with the addition of a bit more code to create a new stream to connect to it.
This is probably only an issue with
periodically and most use-cases wouldn't need this extra step.
Thanks for that. I wonder what I'm doing wrong... It looks like the problem is with my code.
Yeah. A minimal working example helps. I've pushed to yada master. Generally I find bugs are in my code not in manifold or core.async ofc
It appears that the on-close handler for the stream might not get called until I next try to use the stream.
hmm. When I tested earlier I got the println as soon as the client disconnected - iirc
it might depend if the client calls
.close() on the event source, or the browser tab just gets closed?
okay, when killing the webpage I have to wait for something to happen on the channel it seems
I would imagine that in most circumstances this is fine, as the server generates the events
In my case I’m bridging between two clients to establish WebRTC connections, so all the action is initiated on the clients - but I’m pinging the connection periodically now, so it will get cleaned up nicely if there is no longer anyone at the other end.