t x <mailto:txrev...@gmail.com> March 9, 2014 1:43 PM Hi,Before core.async, the way I did event handling in cljs was: ## approach 1 goog.events.listen(... , callback-func) After learning core.async, I read (and liked the idea of): ## approach 2 * (defn global-events (core.async/chan 10000)) * shove all events on to global-events * have a go-thread <! from global-events and process there ### Question I'm now shifting back to liking approach 1 a bit more. The reason being: at the point where I define the GUI element, I also define it's behavior. Approach 2 has this weird "coupling", where it's like: I'm going to define my GUI elements at location X. Then, at location Y, which centralizes event processing, I'm going to define how each event is handled. What are people's takes on this? Am I doing approach 2 incorrectly, or does approach 1 actually has it's merits? Thanks!
-- Sam Ritchie (@sritchie) Paddleguru Co-Founder 703.863.8561 www.paddleguru.com <http://www.paddleguru.com/>Twitter <http://twitter.com/paddleguru>// Facebook <http://facebook.com/paddleguru>
-- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en--- You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
<<inline: compose-unknown-contact.jpg>>
