This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 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 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
oh you’re actually trying to apply advanced optimizations to imported react components?
@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.
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.)
It may not be the most elegant or forward looking one, but it's guaranteed to work
Depends on how you define robust. Most npm packages are anyway browserified by webpack or similar tool by the author or by cljsjs scripts.
Correct, but at some point you'll need a more recent version of a package, or one that hasn't been packaged
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.
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, ...
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
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 think that's right. It feels like it should be labeled "alpha" until 90% of npm modules just work
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.
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
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