This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-02-22
Channels
- # announcements (10)
- # babashka (40)
- # beginners (192)
- # calva (9)
- # cider (2)
- # clj-kondo (9)
- # clojure (69)
- # clojure-dev (15)
- # clojure-europe (29)
- # clojure-gamedev (6)
- # clojure-italy (2)
- # clojure-nl (41)
- # clojure-spec (49)
- # clojure-uk (11)
- # clojurescript (68)
- # conjure (1)
- # cryogen (20)
- # cursive (37)
- # data-oriented-programming (10)
- # data-science (4)
- # datahike (7)
- # datomic (8)
- # depstar (14)
- # emacs (7)
- # events (2)
- # figwheel-main (1)
- # fulcro (81)
- # honeysql (22)
- # hugsql (5)
- # juxt (3)
- # leiningen (8)
- # lsp (314)
- # malli (20)
- # meander (15)
- # membrane (20)
- # mid-cities-meetup (11)
- # practicalli (2)
- # reagent (2)
- # remote-jobs (2)
- # ring-swagger (1)
- # rum (3)
- # sci (21)
- # shadow-cljs (52)
- # startup-in-a-month (1)
- # testing (9)
- # tools-deps (41)
- # vim (8)
- # xtdb (4)
Has anyone here ever seen shadow unable to use a specific library because the underlying library cannot be converted from ES6 in the closure compiler?
Specifically, I am trying to use https://www.npmjs.com/package/mapbox-gl which is published as an ES6 bundle
if it cannot be converted you can turn of the conversion via :compiler-options {:output-feature-set :es6}
or :es7
:es8
. depending on what makes sense
Thank you @thheller
It does look like it can't be, without more advanced transpilation config anyway (it depends on webworkers)
unless you need really old browser support :es6 is a reasonable setting. I might even make it default soon (since Closure will do that as well)
Yep, that fixed it! Apologies for not consulting the user guide before bothering you
Thanks for the help 🙏
I wonder if people are seeing slow file change response times from shadow-cljs on M1 macs? This is probably related to the hawk and the underlying file watch service thing, but I thought I'd ask here first if there's a known issue?
@orestis update. I removed hawk entirely and the default JVM watcher seems to be faster.
@thheller Ok, it seems the problem I have written about yesterday (but messed up the handle) "For some time, I was unable to load the development version of our ClojureScript project on localhost in Chromium. It worked in Firefox, but was rather slow. I didn't know at all, what caused it. So I tried to gather some data about it. I cleared the cache of Chromium (deleted ~/.cache/chromium) and this helped a few times but the problem always returned. I have resorted to deleting of the build directory of shadow-cljs. The result was that the development version of our project loaded immediately in Chromium and Firefox as well. I don't have any further data, just wanted to let you know."
It seems, the problem stems from shadow-cljs watch
since the problem doesn't happen when a release is built. I tried this with 2.11.11 and 2.11.18 and there was no change. I am on Debian Testing, none of my colleagues with Windows are experiencing this but for me, I am basically unable to work efficiently - there are no development tools for ClojureScript in Firefox. Chromium seems to be hit by this bug somewhat harder. What further debugging steps do you propose?
when it compiles and you get the "build completed" message. what numbers do you see?
When run with shadow-cljs watch
I see:
[:client] Build completed. (1106 files, 9 compiled, 0 warnings, 1.48s)
The release version looks like this:
[:client] Build completed. (1041 files, 895 compiled, 0 warnings, 113.01s)
The Java version is:
java --version
openjdk 11.0.10 2021-01-19
OpenJDK Runtime Environment (build 11.0.10+9-post-Debian-1)
OpenJDK 64-Bit Server VM (build 11.0.10+9-post-Debian-1, mixed mode, sharing)
I tested with shadow-cljs 2.11.18 and 2.11.11 as well. No visible change in behaviour between those.
if so try changing :init-fn some.ns/foo
to just :entries [some.ns]
. that will cause the same code to be included but not called on startup
is it still slow when loading the page? or is the call actually making everything slow? if so that is your code and shadow-cljs can do nothing about that.
:client {:target :browser
:output-dir "resources/public/js/compiled"
:asset-path "/js/compiled"
:module-loader true
:modules {:shared {:entries []}
:main {:init-fn orgpad.client.core/init
:depends-on #{:shared}}
:admin {:entries [orgpad.client.views.administration.core]
:depends-on #{:main}}
:layout {:entries [orgpad.client.layout.webworker.core]
:depends-on #{:shared}
:web-worker true}}
:compiler-options {:infer-externs :auto
:output-feature-set :es6}
:devtools {:after-load orgpad.client.core/mount-root
:before-load orgpad.client.core/stop-web-workers
:watch-dir "resources/public"
:browser-inject :main
:loader-mode :script}}
The init looks like this:
(defn init
"Init function of the client."
[]
(rf/dispatch-sync [:init/starting-app])
(window-events!)
(accountant/configure-navigation!
{:nav-handler #(rf/dispatch [:app/changed-route %])
:path-exists? #(routes/client-routes (:handler (b/match-route routes/routes %)))
:reload-same-path? true})
(webfonts/load!)
(mount-root))
I will try your proposed changeI have done the change:
:main {:entries [orgpad.client.core] ;:init-fn orgpad.client.core/init
:depends-on #{:shared}}
(restarted shadow-cljs watch) and it still hangs and shows "shadow-cljs - Reconnecting ..." in the browser, also the Console output looks pretty much the same as it looked before on such hangInstalling CLJS DevTools 0.9.10 and enabling features :formatters :hints :async
util.cljs:136 CLJS DevTools: some custom formatters were not rendered.
devtools$util$check_custom_formatters_active_BANG_ @ util.cljs:136
browser.cljs:20 shadow-cljs: #6 ready!
react-dom.development.js:24995 Download the React DevTools for a better development experience:
core.cljs:11 csrf-token parsed: 9YQlw8taXECNrtRSbR8y1jjZ3awFctrGTALtx5YpLoTZxxhb0O9xIY1ZGxoTbWFGBF0D5VjbpxwKh6lW
I don't have any notable extensions just Chromium PDF Viewer and CryptoTokenExtension
The Chromium is: Version 88.0.4324.146 (Developer Build) built on Debian bullseye/sid, running on Debian bullseye/sid (64-bit)
why the the shadow-cljs websocket reconnecting? what do you see in the network tab regarding that?
I don't know. I will try again with all browser cache cleared
weird. try deleting the .shadow-cljs
directory in the project. not a clue why it can't read a file it obviously found?
I don't know. look at the file in your editor and make sure it is readable and so on
I cannot get rid of the csrf-token parsed line - it seems to concern this code:
(def csrf-token
"Value of CSRF token parsed from the metadata of HTML."
(-> "csrf-token" js/document.getElementsByName (aget 0) (.getAttribute "content")))
(js/console.log "csrf-token parsed: " csrf-token)
this is the line 11
you don't have to get rid of it. all code running on startup (without :init-fn
) however directly contributes to load time
The problem is, the load never finishes at all in Chromium...
Sometimes, after a lot of deleting caches etc. it loads but after a few page changes in our SPA the problems is back again
Sure. Me neither thank you for your time and effort
Is there a quick way to tel the dev-http config to serve files from a virtual /static/
path or should I write a custom handler?
what is a virtual /static/
path? You mean you don't have an actual /static/
directory on disk? that case would require a custom handler.