This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-10
Channels
- # aleph (1)
- # announcements (21)
- # babashka (3)
- # beginners (98)
- # calva (2)
- # circleci (3)
- # clara (58)
- # clj-kondo (123)
- # cljs-dev (1)
- # cljsrn (7)
- # clojure (162)
- # clojure-europe (2)
- # clojure-finland (7)
- # clojure-italy (5)
- # clojure-nl (6)
- # clojure-sanfrancisco (1)
- # clojure-spec (1)
- # clojure-survey (17)
- # clojure-uk (70)
- # clojuredesign-podcast (2)
- # clojurescript (46)
- # cloverage (5)
- # cursive (2)
- # data-science (22)
- # datascript (1)
- # datomic (60)
- # emacs (3)
- # figwheel-main (1)
- # fulcro (26)
- # graalvm (5)
- # jackdaw (3)
- # leiningen (8)
- # luminus (1)
- # off-topic (8)
- # other-lisps (2)
- # pedestal (27)
- # re-frame (17)
- # reagent (20)
- # reitit (3)
- # shadow-cljs (37)
- # spacemacs (23)
- # sql (69)
- # tools-deps (2)
- # utah-clojurians (9)
- # xtdb (3)
Hi there! I'm having a very weird Uncaught TypeError: XR.V is not a function
error that happens only in chrome versions 79.*. Both chrome 78, 75 and Firefox loads the page just fine.
Is anyone else having issues with Chrome 79?
We use lein-figwheel
XR
is a global var in Chrome, probably some Browser API
so looks like your genereted JS clashes with Browser’s env
your generated JS should be wrapped into self invoking function then
Here’s compiler option you need https://clojurescript.org/reference/compiler-options#output-wrapper
IIRC, an updated version of Google Closure Compiler handles the XR
issue. So likely an upgrade of whatever CLJS build tools is used would fix it.
It has been discussed before, and if my memory serves me well, an update of shadow-cljs has fixed the issue. No idea about other tools.
as for updating GCC, it ships with ClojureScript, so you’d need to overwrite GCC version then
how are people dealing with large clojure/clojurescript projects? we have a project which is becoming quite large and very slow to work with
so the figwheel-main reload takes up to 10 seconds maybe, depending on what file you change
I also get a few thread starvation issues with jetty sometimes, so somehow it's consuming lots of resources
I tried to look with VisualVM to get some insight of what is the problem but I could not find that much, possibly we just have too many dependencies and we load everything at startup
it's a massive SPA with re-frame in short, with the API deployed together with it
in figwheel :recompile-dependents
defaults to true. making that false can make things faster, but might make hot-reload a bit unreliable
yeah one colleague is using that, but I would like a more proper solution.
I was wondering if maybe we could use Lein for the API and shadow for the Frontend exactly
otherwise people use the REPL approach. so no hot-reload at all and rather trigger updates from the REPL
that is generally a lot faster but requires pressing a few keys instead of just saving
yeah sure, well the best thing about figwheel-main & is the live reload, would like not to lose that. does anyone use lein+shadow in the same project? I guess the deployment maybe becomes a bit more tricky, but well we can then deploy API and frontend separately
which in a way could be a good thing, we might just lose some CLJC goodness though in the process, which might not be such a big issue though
well I mean splitting the project into two really, backend and frontend, so there would not be an opportunity to share code anymore
the other thing I find quite hard is to measure where the time/ram usage goes, specially when the project loads the first time or does a live reload
shadow-cljs will tell you exactly where time goes with verbose. dunno about figwheel though
ah ok nice, ok then I'll do some experiments
hi, anyone feeling like helping me catch remaining issues with new Dirac release? thanks! please follow quick start here: https://github.com/binaryage/dirac#quick-start I wonder if you can complete it on your system (mac/linux)
So, I thought I'd give this a shot, but fell over at the first hurdle: installing Dirac. Is there a particular version of shasum that you need?
ah, thanks I looked at shasum man page under macOS, it looks like -p is not supported elsewhere
ok, please give it another shot: https://github.com/binaryage/dirac/commit/b753c699cc0aaba22211432bdbc16c3c652a8805
I am on MacOS, but maybe not the same version. I'll give it another shot.
This is what happened when I tried to run it. I have the full report, if you need it.
could you try running env DIRAC_CLI_VERSION=master dirac
, that should clone master and use deps.edn there, so it should work around that issue
clojars agrees that clojurescript dep is not there: https://clojars.org/binaryage/dirac alternative workaround would be to include clojurescript on your classpath by default, but I don’t want to go that route
this should fix it for next release: https://github.com/binaryage/dirac/commit/ab19a8d93b79e202a2e5d402c1eb95ad4baa0770