This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # beginners (16)
- # boot (22)
- # cider (96)
- # clojure (146)
- # clojure-dev (5)
- # clojure-germany (7)
- # clojure-greece (3)
- # clojure-italy (5)
- # clojure-japan (76)
- # clojure-russia (6)
- # clojure-seattle (1)
- # clojure-sg (1)
- # clojure-uk (19)
- # clojure-ukraine (1)
- # clojurescript (114)
- # code-reviews (11)
- # datomic (42)
- # editors (4)
- # euroclojure (3)
- # jobs (18)
- # ldnclj (59)
- # off-topic (1)
- # om (17)
- # reagent (5)
- # yada (43)
so I'm working on some helper functions for event handling in cljs and have the following:
I like that on the consuming side of this function I can setup my event listeners like this:
(defn listen! ([channel func] (go-loop  (func (<! channel)) (recur))) ([src event-type func] (events/listen src event-type func)))
So I can easily mix between traditional callbacks handling the events or async.core style handlers that take from a channel.
(defonce listen-for-dom-viewport-resize! (poly/listen! @rc-cha-dom-viewport-resize on-dom-viewport-resize)) (defonce listen-for-dom-window-load! (poly/listen! js/window "load" on-dom-window-load)) (defonce listen-for-env-mouse-move! (poly/listen! @rc-cha-env-mouse-move on-env-mouse-move))
What I'm not sure about is whether it's a bad design choice to define
listen! the way I did since I'm taking advantage of the fact that I have a different arity, but the parameters are unrelated. So I could split the function into something like:
But with that I lose the simplicity (or is it just easiness?) on the consuming side. Any thoughts?
(defn listen-take! [channel func] (go-loop  (func (<! channel)) (recur))) (defn listen! [src event-type func] (events/listen src event-type func))
@meow: In my opinion, you’re actually adding complexity by having such different behavior based purely on arity. You’re saving yourself a bit of typing, but I think you’re still burdened as the caller to understand that the two different signatures are quite different.
At the same time the similarity is in the intent on the consuming side: I've got a func that I want to get called whenever an event happens - whether the event is coming from the js environment or from an async channel.
I also have a
listen-put so if I separate all concerns I end up with the following:
(defn listen! [src event-type func] (events/listen src event-type func)) (defn listen-take! [channel func] (go-loop  (func (<! channel)) (recur))) (defn listen-put! ([src event-type channel] (events/listen src event-type #(put! channel %)) channel) ([src event-type channel subject] (events/listen src event-type #(put! channel subject)) channel))