This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-07-01
Channels
- # 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)
@clojuregeek: totally cool
so I'm working on some helper functions for event handling in cljs and have the following:
(defn listen!
([channel func]
(go-loop []
(func (<! channel))
(recur)))
([src event-type func]
(events/listen src event-type func)))
I like that on the consuming side of this function I can setup my event listeners like this:
(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))
So I can easily mix between traditional callbacks handling the events or async.core style handlers that take from a channel.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:
(defn listen-take!
[channel func]
(go-loop []
(func (<! channel))
(recur)))
(defn listen!
[src event-type func]
(events/listen src event-type func))
But with that I lose the simplicity (or is it just easiness?) on the consuming side. Any thoughts?@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.
@alejandro: Right, that's one of my concerns.
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))