This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-20
Channels
- # bangalore-clj (3)
- # beginners (30)
- # boot (117)
- # braid-chat (6)
- # carry (9)
- # cider (6)
- # clara (11)
- # cljs-dev (28)
- # cljsrn (12)
- # clojars (2)
- # clojure (114)
- # clojure-austin (2)
- # clojure-dev (1)
- # clojure-dusseldorf (1)
- # clojure-greece (47)
- # clojure-italy (5)
- # clojure-russia (79)
- # clojure-spec (121)
- # clojure-uk (133)
- # clojurescript (92)
- # community-development (67)
- # copenhagen-clojurians (1)
- # core-async (25)
- # cursive (67)
- # datascript (1)
- # datomic (34)
- # devcards (24)
- # emacs (8)
- # funcool (71)
- # juxt (1)
- # keechma (2)
- # lein-figwheel (6)
- # luminus (8)
- # mount (17)
- # om (135)
- # om-next (13)
- # onyx (147)
- # pedestal (11)
- # planck (7)
- # re-frame (42)
- # reagent (86)
- # rum (11)
- # specter (6)
- # testing (6)
- # untangled (1)
- # vim (6)
- # yada (24)
@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
Ya I figured it was std behavior-- just also figured there were a std solution (and yours sounds like it should be)
@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
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
"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?
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
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
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
can't we exclude those (foreign) libs from closure compilation?
yes use externs or https://github.com/binaryage/cljs-oops
We might anyway get extern inference in future
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 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
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
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)