This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-08-09
Channels
- # announcements (16)
- # beginners (86)
- # calva (4)
- # cider (17)
- # circleci (1)
- # clj-kondo (4)
- # cljs-dev (12)
- # cljsrn (4)
- # clojure (82)
- # clojure-europe (2)
- # clojure-houston (4)
- # clojure-italy (5)
- # clojure-nl (7)
- # clojure-spec (49)
- # clojure-uk (19)
- # clojurescript (76)
- # core-async (7)
- # cursive (1)
- # data-science (4)
- # datomic (5)
- # figwheel (1)
- # fulcro (10)
- # graalvm (15)
- # jobs (1)
- # juxt (6)
- # kaocha (2)
- # leiningen (5)
- # random (2)
- # shadow-cljs (25)
- # sql (5)
- # tools-deps (113)
- # vim (3)
- # yada (14)
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
@U3MRWH35M What does the :loader-mode :eval
do?
https://clojureverse.org/t/improving-initial-load-time-for-browser-builds-during-development/2518
Thanks! Also shocking that article contains the exact answer someone else just asked in channel, you have psychic powers or something 😛
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.
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
The memory on my machine doesn't appear to be under much strain and I have tried completely restarting chrome
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?
@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
The article was written a year ago, I can't believe it uses the EXACT same example you provided.
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
So including the full import will allow Shadow CLJS to only bundle the needed dependencies (simmilar to tree shaking webpack)
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:
Oh okay. Thanks for the response @thheller. I guess I'll have a big list of them then 😄
@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
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?