ok cljs people, i have some js questions regarding event handling - maybe some folks can help me w/ my design

preventDefault vs stopPropagation

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?

otherwise, can people confirm that they’ve never needed that?

@bbloom: one case that you can use stopPropagation without preventDefault is on modal, let'

@bbloom: I'm trying to understand why are you looking for a case like that

i’m hoping to prove that i don’t need that case

because preventDefault and stopPropagation have clear distinct functions I think

I often use preventDefault without stopPropagation

is that b/c you WANT propagation, or because the propagation is harmless?

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)

in my experience, it’s the latter

I think makes sense to always propagate, unless some special cases (like modals)

why?

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

when I click on the child*

if you stopPropagation on the child, the parent will never receive the event

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

that depends on how you are structuring it

I think

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

seems to me like it’s complecting capture and bubbling

if you want an event regardless of child handling, you should capture & get the event on the way down

not on the way up

but the events are fired from bottom up, how would you get it before on the parent?

sorry, I think I understand you now

via capture: http://www.quirksmode.org/js/events_order.html

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

so you’d rewrite a :click to a :submit or a :submit to a :signup

the _ 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)

well return false is weird for javascript b/c you have to explicitly return something & ‘false’ isn’t exactly self-explanitory

“returns the event to bubble” seems easy to explain

sure, I actually like the convenience

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.

ok i’ll try this: https://github.com/Prismatic/schema/blob/master/src/clj/schema/macros.clj

@bbloom: Glad to see you couldn’t resist cljs-vdom in the end

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.

... and now it's working. The only change was I rebooted (for other reasons). Fun!

@curtosis: Windows by any chance? (sorry, couldn’t resist)

@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 cljsjs packages

cljs.bootstrap could be an alternative

@shaunlebron: already thought about that but it’s a bit too long

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

i.e. not for apps the way cljsjs.foo is

that makes sense

right now cljs.js creates about 5MB of JavaScript

I’m far more concerned about people abusing eval-str than any confusion with CLJSJS

right

I’m not sure how I feel about discouraging the use of things through obscurity

you mentioned some time ago that some things shouldn’t be documented to discourage use of some things

just a bigger topic I have to think about for the website

cljs.js isn’t going to be obscure

it’s a thing, a footgun thing that can be used for awesome or for messes

right, it’ll be documented, but it’s namespace is non-descriptive I think

but you’ve addressed the confusion point already

@shaunlebron: yeah I’m not really concerned about the non-descriptive part

the idea was cljs.js and cljs.jvm

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

it doesn’t need to be descriptive for any other kind of user

fair point

@dnolen: btw, nice txjs talk, really enjoyed it

@shaunlebron: thanks! hard to talk about CLJS in 25 minutes to a non-Clojure audience

in case anyone missed it: https://youtu.be/6lEbk7xdlsQ?t=9h25m11s

@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

25 minutes, haha, too short

@shaunlebron: yeah the audience was definitely impressed by the demos - it’s really not that good for JavaScript at all

being able to demo 3 different kinds of environments that all the work the same is no small feat

thanks to the CLJS community we’re moving far fast

(and that’s ignoring this stuff also works in Rhino which is ancient as well as Nashorn)

Is it a known thing that cljs browser-connected REPLs generate stack traces that contain javascript line numbers as opposed to cljs line numbers? I'm using piggieback with weasel ...

👏 yeah that was really good to see all those environments working back to back

@pmooser: piggieback and weasel are 3rd party tooling

@pmooser: also you need to make sure the browser environment is configured correctly (usually you need devtools console to be open)

as well as the corresponding “Use JavaScript Source Maps" setting enabled

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

cider + ClojureScript to be specific. cider + Clojure seems fine.

@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.

http://wingolog.org/archives/2015/07/27/cps-soup

@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

but’s not going to be a short trip

also I keep saying if people will listen but I’m going on month 6 with Cursive w/ no nREPL at all

I now have zero problems

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)

the only thing I miss is org-mode

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?

@shofetim: I’ve been doing Clojure for 7 years

Cider went through a terrible unstable phase and was behind swank-clojure by 3 years in terms of features

never had a debugger that ever worked

IntelliJ has world class JavaScript support, Cursive has accurate Clojure debugging, eval in frame, YourKit integration, Node.js standard library indexing, trivial to index Google Closure

could go on forever really

it makes what I was doing in Emacs look primordial

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.

the question is has cursive come out of the paredit uncanny valley?

That is my only hang up that keeps me in emacs

@shaunxcode: the only acceptable paredit I’ve used besides Emacs

the other import thing for a long time Emacser - sticky selection

this alone made me drop pretty much everything else until Cursive

can’t reprogram these hands

@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

my IntelliJ is just tabs, no chrome at all

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

For those interested, I just released a snapshot version of https://github.com/bensu/doo that allows for :optimizations :none and autocompile while testing. Feedback welcome!