This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (3)
- # boot (8)
- # cljs-dev (10)
- # clojure (87)
- # clojure-art (6)
- # clojure-dev (13)
- # clojure-japan (8)
- # clojure-russia (60)
- # clojure-sg (2)
- # clojurescript (126)
- # clojurewerkz (1)
- # core-logic (10)
- # cursive (6)
- # datomic (30)
- # editors (10)
- # ldnclj (7)
- # off-topic (114)
- # onyx (7)
- # re-frame (7)
- # reagent (37)
ok cljs people, i have some js questions regarding event handling - maybe some folks can help me w/ my design
i know the difference, but i’m having a hard time articulating when i’d want one without the other
i’ve had to use preventDefault on a-tags and such, as well as stopPropagation on click events for nested things
you can use stopPropagation w/o preventDefault in many cases b/c there is no interesting default to prevent
can somebody describe to me a case where they’ve needed to preventDefault BUT NOT stop propagation, or vice versa, in their om/react/whatever apps?
@bbloom: one case that you can use stopPropagation without preventDefault is on modal, let'
and I find myself having to use stopPropagation when handling events inside of the modal (usually I stop the propagation at the modal root element)
because if you attach an event on a parent element (let's say a click), when I click on a child element, I expect the child and the parent events to be fired
I’ve had that on grid games; where clicking a thing on the grid does a thing but the parent still wants to see the event
but if a child handles it, like say a button on a selectable row, then you want propagation to stop
if you click the row, it toggles the selection, but if you click the button, it shouldn’t change the selection
I may have done it elsewhere as well; that one just comes to mind because that’s where I learned the difference
a more common example that I can think is nested elements that have mouseover/mouseout events
if you want an event regardless of child handling, you should capture & get the event on the way down
but the events are fired from bottom up, how would you get it before on the parent?
yeah, I agree with you that you can surely do it without ever propagating, I guess I'm just biased because I'm really used to think on events this way
so i’m implementing my own event routing that should be more functional. my current thought (for bubbling only at the moment) is to have
(defn handler [event & _] event) would be the default handler…. the return value is nil for “stop propagation AND prevent default” but you can do something like
(defn handler [event & _] :new-event) to prevent-default by rewriting the event in to your domain
_ represents the part you can’t rewrite. i’m not sure what is in there yet, but i think minimally it would include the “route”, including which component was clicked or handled the events, etc
I just think some people went there before (like React, and jQuery) and they are currently deprecating the "return nil/false" for stop both, I don't know the real reason but I guess is to avoid confusion (I guess because by then the user of your lib will have to know your decision about what to do with the response)
I'm just poiting it out because React really annoys me even when I return false by accident there, hehe
ok, well, i’m going to explore this route (heh) a bit, but if anybody has any more thoughts on it, feel free to chime in
i am pretty stoked about this: https://twitter.com/BrandonBloom/status/625559806091247616
there’s still a fair amount of low hanging fruit, but that’s fast enough now that i can totally ignore the vdom impl perf-wise and work on the component layer
is it possible to write a macro with generates different code for cljs than for clj? i can’t use reader conditionals because the macro is used by the clojure cljs compiler and so read as clj.
luminus is giving me agita. cljsbuild produces js resources which the server doesn't serve; figwheel says it compiled resources/public/js/app.js but in fact has deleted the js directory. sigh.
@colin.yates: nah, Yosemite. Not sure what I did to get my shell so wedged, but so it goes.
@dnolen: just wanted to raise the issue of
cljs.js possibly being confused with
I’m also not concerned about confusion either, we’ve had decent errors about namespaces & definitions that don’t exist for a very long time.
cljs.js is also not really something anyone should be reaching for without a really, really good reason
you mentioned some time ago that some things shouldn’t be documented to discourage use of some things
right, I’ve seen the “ClojureScript JS” and “ClojureScript JVM” terms to describe the compiler split
the namespace is pretty low-level, so far the only people using it are people who are building REPLs or tooling
@dnolen: yeah the talk about change in the beginning was really connecting. the flurry of tool demos was still good to show its current state I think
being able to demo 3 different kinds of environments that all the work the same is no small feat
(and that’s ignoring this stuff also works in Rhino which is ancient as well as Nashorn)
@pmooser: also you need to make sure the browser environment is configured correctly (usually you need devtools console to be open)
Thanks dnolen - I'll keep digging. I realize this is probably due to some configuration option. Maybe I'll try to move to the stock browser-connected REPL and go from there.
Ah, I remember now - I'm using piggieback because cider seems to need it for cljs. I'll investigate alternatives.
@pmooser: people have got cider working but it seems far finickier than the alternatives
@dnolen: Yeah, I use it with clojure with no issues. Just trying to find a nice way of working with cljs with a repl - it might be best for me to ditch cider for cljs to reduce the number of moving parts.
@pmooser: inf-clojure works great, I suspect in the next 6 months cider will work quite well with ClojureScript w/o so many moving parts
also I keep saying if people will listen but I’m going on month 6 with Cursive w/ no nREPL at all
Cursive seems excellent but I'm not sure I can get away from emacs ... I mean it's possible obviously but I really like parts of it. I'm not enamored of the clojure-specific tooling due to its highly volatile and magical nature. Maybe I'll give cursive a try. I met colin at clojure/west and he was a hell of a nice guy.
I was an Emacs snob, IntelliJ appears to be designed with a pretty good understanding of what’s good about Emacs (sans endless configuration)
my only real complaint with IntelliJ is that you have to be a bit careful w/ project configuration on a slower machine due to constant project indexing.
@dnolen: I don't want to start a flame war, but I am very curious, why move from emacs to cursive? Was there a particular feature that cursive had and emacs lacked?
Cider went through a terrible unstable phase and was behind swank-clojure by 3 years in terms of features
shofetims scratches head and feels primordial. Ok, I will have to poke at this cursive thing and see if it drives better then emacs for me too.
@dnolen I think intellij is a nice environment, but my experience with both eclipse and intellij is that they make emacs seem rather "lean and mean" which is quite an accomplishment. I'm sure I could adapt ...
@pmooser: from what I can tell most people never actually take the time to configure IntelliJ
Yeah, OK ok I will give cursive a try. I've been doing clojure forever but I shouldn't get stuck on old tooling.
and typing in a syntax highlighted 10,000 line ClojureScript standard library isn’t any faster in Emacs
While I’m a very happy Emacs user, I am extremely excited about the potential effect of the more IDE-like options for clj/cljs adoption in the broader community — it’s really good for all of us