@johanatan i think that's standard DOM behavior for mouseenter/`mouseleave`. i'm not sure if there's a better/more modern/more idiomatic way to proceed, but i'd be looking at js/document.elementFromPoint and dispatching another mouseenter if the element differs

Ahh good call. Thx!

Ya I figured it was std behavior-- just also figured there were a std solution (and yours sounds like it should be)

[of course you'd also need to send mouseleave to the previous element]

@reefersleep Re: my api proposal. I did a crude implementation and a pull request: https://github.com/reagent-project/reagent/pull/263

Someone said few days ago about upcoming feature to have npm packages available without cljsjs?

@artur I think this is the subject of an upcoming lambdaisland episode

https://twitter.com/plexus/status/777888654081593344

I don't think it's quite there yet

(simply using npm modules using the Closure compiler I mean)

"es6-leftPad" method mentioned there is the one that is interesting

but Cljs compiler and possibly Closure need work before this will be usable

Module processing already works for simple cases, like one CommonJS module

But consuming complete npm projects, with dependencies to other npm projects needs work

the gains from this will be significant though

when it works

I'm assuming the Google Closure developers are keen to tap the NPM universe as well?

I guess so. They might have the support already, there just isn't much documentation.

Unfortunately module dependency resolving done by Closure is pretty much hardcoded for their own usecases

interesting

https://github.com/google/closure-compiler/wiki/JS-Modules

"Full module interop requires the 20160517 release or newer."

we are still on 20160315

Also "When using the grunt/gulp plugins, the root folder is the current working directory of the compiler when executed. Otherwise, the root directory is the root of the filesystem."

And in Cljsjs case the files would be on classpath, instead of file system

well it would be cool to use NPM directly, without going through cljsjs

we need deps.cljs anyway

and I don't see what's cool about npm, I would avoid that nearly at any cost

I'm definitely not a fan

but it has 1000s of packages available

at least as an intermediate step, before pushing libs to cljsjs, it would be great to be able to access those

With module processing and extern inference Cljsjs will be different, there won't be need for any manual packaging

what is deps.cljs needed for?

for the :foreign-libs key?

to define that the file needs to be processed as CommonJS library

{:foreign-libs [{:file "..." :provides ["react"] :module-type "commonjs"]}]}

I see

do we need that for each dependency of the library too?

Yes

many libraries have dozens of dependencies

I'm not sure, but I think at least for any file you want to depend on from Cljs

right, that would only be the entry point library then

But I have already tested generating these deps.cljs automatically from npm packages

package.json + boot task => n jar files with dependencies to each other and complete deps.cljs files

There are a couple things that are still big blockers for supporting npm modules

Many packages use webpack or rollup, and their umd-ish output is not understood by closure

If the npm package also contains uncompiled sources then that might be an option though, also something that could be automated, eg detect rollup config and use the same es6 file as entry point

But even with all that, many libs will not conform to the rules of closure, and so even if their packages are understood the code will break in advanced optimization

Hmm, in what case advanced compilation will break stuff?

One case I think is problematic is when module adds stuff to module.exports in a loop

For instance, check out the es6-d3 branch in that repo

Doing an advanced compilation results in tons of warnings, and running it shows there are things that have been renamed in a way that breaks the code

"unsafe use of this" is a common warning

can't we exclude those (foreign) libs from closure compilation?

If you keep using externs, that's basically what we do now

Currently any foreign libs just get concatenated into the final artifact unchanged

yes use externs or https://github.com/binaryage/cljs-oops

Well yeah, but that's really a last resort IMO

We might anyway get extern inference in future

Then you might as well write an externs file manually

well I see it more as a "works for now" solution; once that's done you can improve on that

but just getting npm modules to work somehow would be cool

because it enables something you weren't able to do before

I agree, and it could make cljs much more attractive to js devs

I wonder if it is possible to mix optimization modes - pass cjls to advanced and npm to simple mode

I just ran into this because I wanted to include https://github.com/github/fetch in planck to experiment with the new API

the fact that this uses commonjs is another barrier

Commonjs is also supported by closure, but many libs that are "commonjs" really have this funky module type checking usually referred to as UMD

Closure also supports UMD, in theory. In practice everyone has their own variant and so it won't detect that properly

maybe we can get around that using some kind of shim/wrapper?

If closure could get support for the format that rollup and webpack spit out that would be massive, but I'm skeptical if someone will get that in

A shim would work if it was a runtime concern but this is compile time. What would work is a preprocessing step that rewrites the code so closure's static analysis knows how to deal with it

interesting

great that you're looking into this btw

It's funny, you bang your head against the wall for a week and next thing you know you're kind of the expert ;)

I might even make this a freebie episode because that information just isn't comprehensively available elsewhere, and it's really important for the ecosystem to be able to develop

hi guys, how i can watch reagent component state? i'm trying apply reagent/state to my component but it always returns nil

i'm trying to apply these functions to the object returned by reagent/render

sorry to reply to a question with a question, why are you using component state?

usually it's better to use a ratom or props instead

i'm developing a tool for monitoring reagent components, so i need information about their state, mounted they or not

so the great thing will be if i can get tree of mounted components

or listen global events. componen did mount

that's probably more of a react issue then?

as fas as I know, reagent.core/state works for the current component primarily (in render and lifecycle methods)

ok, thank you