Fork me on GitHub
#shadow-cljs
<
2019-08-09
>
kasuko15:08:23

Has anyone encountered Chrome throwing insufficient resource warnings in dev mode because it's trying to fetch too many JS files?

GET  net::ERR_INSUFFICIENT_RESOURCES

neupsh15:08:41

try

:devtools {
                   :loader-mode :eval
}

neupsh15:08:59

:loader-mode :eval in :devtools of your build in shadow-cljs.edn

kasuko15:08:13

Giving it a go

kasuko15:08:24

Not sure if it's related but now I seem to be unable to compile my application

kasuko15:08:05

Oh, that only happens if I try npx shadow-cljs watch app without a running server

kasuko15:08:19

If I start the server first then watch the app it works fine.

kasuko15:08:35

@U3MRWH35M What does the :loader-mode :eval do?

neupsh16:08:29

essentially creates one <script... tag instead of many

kasuko17:08:51

Thanks! Also shocking that article contains the exact answer someone else just asked in channel, you have psychic powers or something 😛

neupsh18:08:23

lol . I had read that article when it came out, but didn't need it recently. so i had to ask what was that configuration to do that in the channel some weeks back. now I remember it pretty good.

kasuko15:08:13

Currently converting a large project from Leiningen to Shadow-CLJS and the number of requests went from 675 with lein+figwheel to 1739 requests with shadow-cljs

kasuko15:08:46

The memory on my machine doesn't appear to be under much strain and I have tried completely restarting chrome

alpox15:08:00

I have a short question regarding import/requires of npm libraries. Some libraries - for example RXjs and Material-UI export their components in isolation (So the import would be basically ["@material-ui/core/Button" :as Button]) - which is the recommended import. I remember this enables easier Tree-Shaking for Webpack. Is there any downside in just importing multiple exports at once ["@material-ui/core" :refer [Button CircularProcess]] in shadow-cljs? I guess google closure should be able to remove unnecessary code well enough or am I mistaken?

kasuko17:08:49

@alpox Well completely independant of your question I was linked this article to solve my unrelated problem, but it contains exactly your answer https://clojureverse.org/t/improving-initial-load-time-for-browser-builds-during-development/2518

kasuko17:08:55

The article was written a year ago, I can't believe it uses the EXACT same example you provided.

kasuko17:08:48

As for your thoughts on the Google Closure compiler, I do know that the code from NPM is only run through :simple optimizations which means it won't do dead code removal

kasuko17:08:35

So including the full import will allow Shadow CLJS to only bundle the needed dependencies (simmilar to tree shaking webpack)

alpox17:08:43

@kasuko Wonderful. Thanks! It works like charm 🙂

alpox17:08:17

I tried it before without loader-mode set to eval and the icons import took years when I referred to the whole icons namespace. It works now as before with a specified import :thumbsup:

thheller17:08:02

@alpox :refer does nothing for DCE. you need the specific imports for now

alpox17:08:57

Oh okay. Thanks for the response @thheller. I guess I'll have a big list of them then 😄

kasuko18:08:25

@alpox Sorry didn't mean to indicate that the :loader-mode solved your question. I was stating that the article which solved a completely different problem had a "side rant" in it that actually answered your question

deadghost18:08:37

I'm looking at code splitting. https://github.com/thheller/code-splitting-clojurescript/blob/master/src/main/demo/app.cljs I take it there's currently no way to require a lazy loading namespace in :require and I need to def lazy-component wrap each fully qualified namespaced component. Is that right?