This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-04
Channels
- # aws (1)
- # beginners (163)
- # boot (1)
- # bristol-clojurians (1)
- # cider (7)
- # clara (1)
- # cljs-dev (22)
- # cljsjs (1)
- # clojure (43)
- # clojure-denver (1)
- # clojure-finland (6)
- # clojure-italy (1)
- # clojure-nl (3)
- # clojure-russia (1)
- # clojure-spec (1)
- # clojure-uk (6)
- # clojurescript (107)
- # cursive (4)
- # data-science (2)
- # datascript (2)
- # datomic (19)
- # duct (31)
- # emacs (1)
- # fulcro (50)
- # graphql (15)
- # hoplon (3)
- # lein-figwheel (2)
- # luminus (21)
- # off-topic (74)
- # onyx (3)
- # parinfer (15)
- # portkey (2)
- # precept (9)
- # proton (1)
- # re-frame (130)
- # reagent (73)
- # reitit (7)
- # ring-swagger (5)
- # shadow-cljs (61)
- # spacemacs (18)
- # specter (12)
- # uncomplicate (1)
- # vim (88)
- # yada (2)
Did anyone try new :npm-deps
feature? I tried to use one module ( https://github.com/Stanko/react-animate-height ) and include it into Reagent project, but with advanced opmtimization it didn't work. After few hours of debug it seemd that this line in React https://github.com/facebook/react/blob/master/packages/react/src/ReactBaseClasses.js#L26 was optimized away by Google Closure Compiler
@andrewboltachev I have never had luck with the :npm-deps
feature. I do not think it is really ready for prime time use. I would recommend other approaches. https://gist.github.com/jmlsf/f41b46c43a31224f46a41b361356f04d
@lee.justin.m got it. thanks
@lee.justin.m btw my favourite one: http://blob.tomerweller.com/reagent-import-react-components-from-npm (doesn't support "advanced"). Made a template for it: https://github.com/andrewboltachev/rererejs-template
no reason why this shouldn't support advanced
oh you’re actually trying to apply advanced optimizations to imported react components?
the npm modules shouldn't be fed through Closure of course
that's the point of the double bundle approach
it's going to be hard to outperform webpack on its own turf
@pesterhazy If they have externs, why not?
@pesterhazy The whole idea of ClojureScript Node module support is to run Node module code through the same Closure-compiler whole-app optimization as JS emited by ClojureScript compiler. This allows better dead-code-elimination than is possible by using webpack for external deps and Closure for Cljs output.
@juhoteperi lol! why doesn’t it say that in the documentation for the feature? that explains quite a bit of the trouble people have with the feature. given how hard it is to get javascript to compile with closure, that should be a giant red flag.
https://clojurescript.org/guides/javascript-modules motivation section here touches on the topic
now i see at the tail end of of amonteiro’s blog post he mentions in passing that you can do DCE on npm modules. there’s nothing about that in the compiler option entry. why is it even linked? shouldn’t you be able to turn it off? the way most developers (based on my interactions with at least a dozen confused people on slack and including myself) perceive this feature is simply a convenient way of getting access to an npm module
As the Closure optimization is application level setting, no, it can't be turned of just for the npm modules.
i mean, i see how it mentioned dead code elimination at the top, but I don’t see anything in that article that actually says, “hey, if you use this feature and turn on advanced optimizations, you’d better be ready for it”
And that would help, as npm module code needs to be parsed and transpiled into ClosureJS so it can be part of ClojureScript app.
In general I don't think advanced optimizations with npm module is any harder (easier in some cases) than with foreign libs (cljsjs). React is just complex beast and uses does some dynamic things that can cause problems, but these are usually fixable with proper externs, just like problems with foreign-libs.
With simple npm libs externs aren't even needed because Closure will e.g. apply same renaming to both npm JS and Cljs JS code,.
well somehow whatever @thheller is doing results in small code packages and npm integration that is 99% seamless
I think it is super cool to push the boundaries on getting npm modules into whole program optimization, but it is totally unfair to beginners not to warn them that if they just want something functional and convenient, then :npm-deps
is not the way to go. They will run into something that requires a deeper understanding of the closure compiler at some point.
Well, my recommendation for pretty much everyone (even for advanced users) would be to use cljsjs / foreign-libs, that is the most robust way for now. (I'm not familiar with shadow-cljs.)
The most robust way is to use webpack
It may not be the most elegant or forward looking one, but it's guaranteed to work
because it uses the same code path as thousands of React projects out there
Depends on how you define robust. Most npm packages are anyway browserified by webpack or similar tool by the author or by cljsjs scripts.
Most cljsjs packages use the same UMD modules as provided by package authors.
Correct, but at some point you'll need a more recent version of a package, or one that hasn't been packaged
The vast React ecosystem dwarfs what is available on Cljsjs
True. My experience here is going to be skewed as being Cljsjs maintainer I can just package anything or update any package as needed.
Which is not to minimize the contribution of Cljsjs — it's a wonderful project and works well
Though I don't want to use that many JS packages, I usually find React + Leaflet enough.
I've used in for years and rarely ran into problems
if you use 3 or 4 react libraries, the version control issue gets out of hand really quickly with a cljsjs type solution
I use react-select, react-native-web, react-ace, react-burger-menu, react-notification-system, react-webcam, ...
add react-bootstrap, react-material
It gives you a huge boost in productivity especially at the beginning of a project to be able to just pick a pre-baked widget off npm
and in some cases like react-virtualized, the functionality is so sophisticated you’ll never replicate it
@lee.justin.m agreed, it's a very clever library
So in principle I agree, start with cljsjs, but as your project grows at the moment you'll want to tap into npm
And building a secondary bundle using webpack is by far the least painful way to get there
(I should note that I have little experience with shadow-cljs)
but the real issue is the “Clojurescript is not an island” blog post and the “javascript modules” page on http://clojurescript.org both breeze past the fact that this feature is super advanced and not at all robust, so new people march straight down this path and then wonder why nothing works
I think that's right. It feels like it should be labeled "alpha" until 90% of npm modules just work
It is labelled alpha, but probably not everywhere.
well that’s the other problem: “alpha” has no meaning given that spec is being used everywhere and is labeled “alpha”
It needs a concrete list of issues and problems at the beginning and a suggestion of what else to use in the meantime.
It's certainly one of the most frequently asked questions in #clojurescript and #reagent on Slack
I'd offer to contribute a webpack integration guide, but I fear it wouldn't be well received
@lee.justin.m Lots of good suggestions here. ClojureScript site is managed on github and takes PRs 🙂
i’ve already written up my thoughts and so has @pesterhazy. can’t spend a bunch of time writing a PR that nobody wants. not sure who makes decisions or what the process is for suggesting bigger changes like that.
About the issue list, I think I might have done something like that somewhere. Reagent 0.8 guide mentions some: https://github.com/reagent-project/reagent/blob/master/docs/0.8-upgrade.md
@juhoteperi does “node modules” in that table mean including react/react-dom via “:npm-deps”?
Yes. This is again a thing that is not really made clear in the docs. :npm-deps
is about installing npm packages during Cljs build, but ClojureScript doesn't care if packages are installed by npm install or what, as long as they are available on node_modules
directory during Cljs build.
(The Reagent 0.8 doc mentions this)
Do you recommend a material-ui wrapper ? Using directly ?
I started by using https://github.com/DaveWM/reagent-material-ui, but then when I wanted to upgrade to beta, I compiled the js as described here: http://blob.tomerweller.com/reagent-import-react-components-from-npm and wrote my own version of https://github.com/DaveWM/reagent-material-ui/blob/master/src/reagent_material_ui/macros.clj
@geraldodev I have used and recommend https://github.com/madvas/cljs-react-material-ui
@geraldodev my general recommendation would be to use it directly; that way you know you can use all the features, instead relying on a wrapper with potentially incomplete docs or coverage
besides using react component from reagent directly with the :>
syntax is fairly seemless
(as for including material-ui see the discussion above 🙂)
n.b. I haven't tried those particular cljs wrappers, so they may be very good; it's just my general experience that it's best to go to the source, if you can
same with using Java libs in Clojure — a wrapper often creates more problems than it solves; what's worse, some are written by authors with an incomplete understanding of the library they're wrapping
@pesterhazy fair point. I came to that conclusion too, in this case because they are migrating to 1.0 and it's a rewrite.
the wrapper @gadfly361suggested is almost on point on the stable version. It uses 0.19 when the stable is 0.20
I'm impressed by the adapters they wrote for auto completion https://material-ui-next.com/demos/autocomplete/