This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-03
Channels
- # adventofcode (198)
- # aleph (10)
- # announcements (7)
- # aws (17)
- # beginners (353)
- # boot (1)
- # calva (13)
- # cider (18)
- # cljdoc (2)
- # cljs-dev (11)
- # cljsrn (1)
- # clojure (87)
- # clojure-austin (1)
- # clojure-brasil (2)
- # clojure-greece (13)
- # clojure-italy (18)
- # clojure-kc (2)
- # clojure-nl (9)
- # clojure-quebec (1)
- # clojure-russia (1)
- # clojure-spec (55)
- # clojure-uk (114)
- # clojurescript (18)
- # clojurex (14)
- # code-reviews (5)
- # core-async (17)
- # cursive (23)
- # data-science (1)
- # datomic (82)
- # docker (8)
- # duct (10)
- # emacs (8)
- # figwheel (3)
- # figwheel-main (5)
- # fulcro (13)
- # hyperfiddle (8)
- # jobs (1)
- # midje (1)
- # mount (1)
- # nrepl (2)
- # off-topic (72)
- # om (2)
- # pathom (10)
- # portkey (2)
- # re-frame (9)
- # reagent (3)
- # reitit (9)
- # ring-swagger (14)
- # schema (1)
- # shadow-cljs (91)
- # spacemacs (21)
- # sql (6)
- # tools-deps (19)
- # unrepl (9)
- # vim (41)
hi, i have a query about pub/sub. what happens to any message if they are not subscribed by any of them. Will they accumulate in the pub channel and prevent further put! Is there a best practice for using pub/sub?
I think that it's a "global pattern" in clojure: if you will call a zero-arg function, example (UUID/randomUUID)
, or (async/chan)
, it's better to let it be a argument.
@pradyumna this is covered in the docstring for pub
: “Items received when there are no matching subs get dropped.”
regarding returning a channel vs. passing one in, I've very often found myself returning channels when building async APIs. for example, those APIs look similar to Datomic Client's async API which do not provide (or need to provide, IMO) a way to pass a channel in: https://docs.datomic.com/client-api/datomic.client.api.async.html
Is it different when your API is a “source” of values (e.g. from some external system) versus a “middleware”?
one piece of guidance I've seen from the Go people is that a function should accept a channel as an argument if it is going to be putting an unbounded amount of data over the channel.
though admittedly I've only really seen it here: https://inconshreveable.com/07-08-2014/principles-of-designing-go-apis-with-channels/
and I wasn't really able to find much discussion about it
In clojure another argument for this is (among others) is that you can create the input chan with an xform (or useful buffer etc)
maybe a way to think of it is, pass a channel in if you would otherwise be passing in a callback/observer. pass a channel out if you would be returning a promise/future.
I'm not sure if that's a very useful distinction though