Fork me on GitHub

@bfast I'm using material-ui-next directly from npm with shadow-cljs, and it works great. For me it was a bit difficult figuring out how to require the different components, as some require using default and some require using refer. Here's my current imports, maybe that will help:

["material-ui/Button/Button" :default Button]
   ["material-ui/IconButton" :default IconButton]
   ["material-ui/Progress/LinearProgress" :default LinearProgress]
   ["material-ui/Radio/Radio" :default Radio]
   ["material-ui/Radio" :refer [RadioGroup]]
   ["material-ui/Form" :refer [FormLabel FormControl FormControlLabel FormHelperText]]
   ["material-ui/Switch" :default Switch]
   ["material-ui/Dialog" :default Dialog]
   ["material-ui/AppBar/AppBar" :default AppBar]
   ["material-ui/Toolbar" :default Toolbar]
   ["material-ui-icons/Menu" :default MenuIcon]
   ["material-ui-icons/Close" :default CloseIcon]
   ["material-ui-icons/MoreVert" :default MoreVertIcon]
   ["material-ui-icons/ExpandMore" :default ExpandMoreIcon]
   ["material-ui-icons/ExpandLess" :default ExpandLessIcon]
   ["material-ui/Menu" :default Menu :refer [MenuItem]]
   ["material-ui/Typography" :default Typography]
   ["material-ui/Card/Card" :default Card]
   ["material-ui/Avatar" :default Avatar]
   ["material-ui/Card" :refer [CardHeader CardMedia CardContent CardActions]]
   ["material-ui/Paper" :default Paper]
   ["material-ui/transitions/Collapse" :default Collapse]
   ["material-ui/TextField" :default TextField]
   ["material-ui/Drawer/Drawer" :default Drawer]
   ["material-ui/List/List" :default List]
   ["material-ui/List" :refer [ListItem ListItemIcon ListItemText]]
   ["material-ui/Divider" :default Divider]
   ["material-ui/ExpansionPanel/ExpansionPanel" :default ExpansionPanel]
   ["material-ui/ExpansionPanel" :refer [ExpansionPanelDetails ExpansionPanelSummary]]
Using the components is then simple, just use the special :> operator reagent provides, for example [:> Card {} ]


@mjmeintjes that :> seems very interesting, I have been using reagent for a long time and I have never heard of it. Can you point me to some docs?


For those interested, just thought I post some pretty cool info: we’ve been porting over a large CLJS app from lein-cljsbuild + a lot of cljsjs and manually created foreign libs over to shadow-cljs and completed that task this morning. The productivity gains are one thing, but tangibly we’ve gone from an uncompressed 9.9MB build to 2.7 MB and gziped 1.4MB to ~700k


Layer on the potential benefits form code-splitting, and that’s a a huge win for us thanks to shadow-cljs


wow interesting @colindresj. Where do you think most of the gains are coming from? I knew that shadow-cljs made it easier to import, but I didn’t realize it would do better at minification


Haven’t done a deep-enough dive to figure it out just yet @lee.justin.m, but I’m guessing that since foreign libs (including those in cljsjs) don’t go through any kind of optimization, there’s a lot of duplication and dead code there


Especially when using JS libraries that are pre-compiled via Babel, I’ve noticed that a lot of our foreign libs contain the same Babel helpers over and over again


I'd be interested in knowing about the optimization benefits too. I had not considered the duplication before, very interesting.


I suppose duplication matters little with gzip though?


the biggest thing that I know shadow allows you to do is reference partial components. e.g. material-ui lets you refer to just the component you are using. that’s actually possible to do in shadow


if you set your foreign-lib up properly, you should be pointing to minified builds during production. if you guys were doing that and you are still seeing gains, that would be pretty amazing


Gzip takes care of shipping the code to the browser, but the browser still has to parse and execute all the duplicate stuff.


@dominicm I think so, which is why the gains at the point of gzip are proportionally much smaller than pre-gzip


@lee.justin.m we were minifying our own foreign libs, hard to know for sure about all the others


@colindresj nice! biggest gain is probably from de-duping some stuff. closure :simple mode (which is used for npm deps) is also pretty good though, so thats part of it too.


but you essentially validated exactly why I wanted to get away from cljsjs.


glad I'm not the only one seeing those results


Hi, I am trying to use beicon with shadow-cljs on node, but getting this: The required namespace "beicon.impl.rxjs" is not available, it was required by "beicon/core.cljc". I skimmed last couple of days and found some similar stuff but somehow I can't get my head around it. The problem I guess is that beicon is using and it is not compatible with shadow-cljs.


npm install rxjs


I'm not entirely sure how the shim file would have to look


(ns beicon.impl.rxjs
  (:require ["rxjs/Rx" :as rx]))

(js/goog.exportSymbol "Rx" rx)


rx is one of those packages where you are better off importing only what you need directly


Ok, I will try it


So at least compilation is working. I will report how it will continue. I started to play with shadow this week and I fell in love.


So this is my first try with small node library. If I manage to work with it, I am planning to move our front-end app to it


Thank you very much again


Well everything is working for me


hehe I did a quick test and rxjs loads 400+ files


thats a bit scary 😛


but it seems to work


It does indeed