shadow-cljs 2021-05-21 | Slack Archive

Aron07:05:51

for 2 minutes today I was panicking that my shadow-cljs setup broke, but then i realized that the webserver i hosted the build was running from a different docker instance than the shadow-cljs server (same directory mounted in two different instances)

Franklin08:05:20

hello, I keep getting the folloiwing error while trying to use https://www.npmjs.com/package/@yaireo/tagify js library,

views.cljs:328 Uncaught TypeError: module$node_modules$$yaireo$tagify$dist$tagify_min.default is not a constructor
    at cmp.eval (views.cljs:328)
    at cmp.reagent$impl$component$custom_wrapper_$_componentDidMount [as componentDidMount] (component.cljs:207)
    at commitLifeCycles (react-dom.development.js:20664)
    at commitLayoutEffects (react-dom.development.js:23427)
    at HTMLUnknownElement.callCallback (react-dom.development.js:3946)
    at Object.invokeGuardedCallbackImpl (react-dom.development.js:3995)
    at invokeGuardedCallback (react-dom.development.js:4057)
    at commitRootImpl (react-dom.development.js:23152)
    at exports.unstable_runWithPriority (scheduler.development.js:469)
    at runWithPriority$1 (react-dom.development.js:11277)

Franklin08:05:39

the require looks like this ["@yaireo/tagify" :as Tagify]

Franklin08:05:36

which corresponds to import Tagify from '@yaireo/tagify'

Franklin08:05:27

and the line where the error is thrown looks like this: (Tagify. html-input-element)

Franklin08:05:19

it's not clear to me why I'm getting this error because it's previously worked ok (but I might be mistaken; 🤷 )

thheller08:05:07

["@yaireo/tagify" :as Tagify] does NOT correspond to import Tagify from '@yaireo/tagify'

thheller08:05:29

see the translation table here https://shadow-cljs.github.io/docs/UsersGuide.html#_using_npm_packages

thheller08:05:10

but it looks like you have ["@yaireo/tagify" :default Tagify]?

thheller08:05:29

maybe need to actually try :as. see the section about default exports in the link above

Franklin09:05:11

ok... so, after messing around for a while and trying different things; this works for me ["@yaireo/tagify/dist/react.tagify" :default Tagify]

Franklin09:05:35

seems there was a better way of using tagify with React that I didn't know about

murtaza5211:05:35

I am using moment js library in my shadow-cljs project. I have tried including both the cljsjs lib and the npm package. The advanced compilation breaks the moment js usage, any leads on how I can make it work ?

thheller11:05:40

breaks how?

murtaza5211:05:21

this is the error I see in the browser console, the page never loads -

Uncaught TypeError: Cra.initializeApp is not a function
    Jra 
    <anonymous> 
    onload

murtaza5211:05:50

There is no error and the app works fine with shadow-cljs watch app

thheller11:05:56

that doesn't look moment related? where do you call initializeApp or what on?

thheller11:05:02

try shadow-cljs release app --debug

thheller11:05:08

maybe that provides a better clue what fails

murtaza5211:05:48

thanks lets me try that

Tomas Brejla20:05:19

Hi. I'm currently not using any "UI component framework" in my cljs app which utilizes shadow. And my compilation times are awesome so far (sub second times for tiny changes : 0.25 - 0.5s). I tried introducing material-ui library to my project. This specific library might be an overkill, really - I just knew that a friend of mine was using it on his project, so I wanted to try it. It's likely I'll not end up using it in the end. Importing the library to my project was easy. But suddenly, even a tiny change in some label inside my namespace resulted in 5-6s compile time instead of sub-1s. No matter how tiny the change was. Would splitting my namespaces into more modules (such as :shared shown in user manual) help here? Or is there any other way of improving the compilation performance?

thheller20:05:32

hmm how did you add it? should only make the compile slower once, after that cache should take care of it

thheller20:05:59

(no, :modules won't do anything regarding performance)

Tomas Brejla21:05:18

Interesting. I have already stashed my changes in the past, so I'll try to do it again from scratch on current (fast) version. But I guess I just npm-installed the library, created a new namespace which :require-d and aliased the library and then used (r/adapt-react-class to make react class adapters.

thheller21:05:52

that should be fine

Tomas Brejla21:05:13

I've done the same and it's super fast now 😄

thheller21:05:34

sometimes helps to restart shadow-cljs if you've just done a npm install. that modifies a lot of files and sometimes shadow-cljs gets out of sync with that

Tomas Brejla21:05:34

is there any "temporary" folder eg. with some caches for shadow-cljs which one might try deleting when really desperate? 🙂

thheller21:05:01

.shadow-cljs/builds but that usually does nothing. restart is enough.

Tomas Brejla21:05:15

Ok, perfect. Thanks

Tomas Brejla21:05:31

@thheller oh, I see the problem now. When I'm only importing ["@material-ui/core" :as mc], it's fine, but once I also add ["@material-ui/icons" :as mi] , the slowness starts.

Tomas Brejla21:05:53

and I'm not surprised 😱

➜  myproject git:(master) ✗ find node_modules/@material-ui/icons -type f | wc -l
16674
➜  myproject git:(master) ✗ du -sh node_modules/@material-ui/icons          
201M	node_modules/@material-ui/icons

thheller21:05:01

oh you shouldn't be doing that anyways. that will add several megabytes to you build and you are likely not using those thousands of icons

thheller21:05:14

just import what you need directly

thheller21:05:14

same for material-ui too basically. those will bloat your build so much

thheller21:05:38

just (:require ["@material-ui/icons/ZoomIn" :default ZoomIn]) instead of (:require ["@material-ui/icons" :refer (ZoomIn)])

👏 2

thheller21:05:57

but yeah adding a couple thousand files to your build might make it slower 😉

Tomas Brejla21:05:23

Indeed 😄. I made a typical textbook mistake. Made too many changes at once. Therefore it didn't occur to me that it was the actual naive import of icons' namespaces which introduced this slowness. I simply thought that it was the library size and complexity which made the compilation slow. Thanks for your help.

2021-05-21

Channels