This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-11
Channels
- # announcements (21)
- # aws (2)
- # babashka (20)
- # beginners (47)
- # bristol-clojurians (2)
- # calva (63)
- # cider (24)
- # clj-kondo (22)
- # cljs-dev (3)
- # cljsrn (6)
- # clojars (3)
- # clojure (147)
- # clojure-europe (21)
- # clojure-france (2)
- # clojure-italy (3)
- # clojure-losangeles (1)
- # clojure-nl (3)
- # clojure-spec (2)
- # clojure-uk (70)
- # clojurescript (37)
- # core-logic (6)
- # cursive (4)
- # data-science (2)
- # datomic (99)
- # events (1)
- # figwheel-main (20)
- # fulcro (26)
- # graalvm (6)
- # graphql (5)
- # kaocha (8)
- # leiningen (20)
- # meander (22)
- # nrepl (4)
- # off-topic (27)
- # pathom (5)
- # pedestal (3)
- # re-frame (20)
- # reagent (4)
- # shadow-cljs (43)
- # spacemacs (11)
- # tools-deps (55)
- # tree-sitter (6)
- # vim (8)
- # xtdb (18)
- # yada (14)
uhm on a relatively single SPA for a personal project it's doing 2148 http requets, to get the gazillion small JS files it needs
I wonder if: • I should try to reduce that massive number (a problem in local dev not prod of course) • how do I let it cache everything except the files that are actually under my control? (I guess if I update a dependency for example I would have to break the cache myself maybe)
figwheel-main
Ah, no idea then, sorry. Shadow-cljs solves this problem by loading it all as a single file.
I use shadow for a few other projects, and well if I do the non basic compilation I probably get the same with figwheel-main
or maybe I should use figwheel-main ring server instead of my own
the :none, so the default
As we noted before the :none level does not produce a single self-contained compiled artifact, but rather creates an artifact that loads all of the separately compiled namespaces.
All the other levels (:whitespace, :simple, and :advanced) produce a single compiled artifact to the :output-to file. These are often used for producing your final deployable asset when you use these optimizations settings.
from that page, so yeah maybe I can just try with that
I'm not sure that the :optimizations
option by itself has anything to do with the way the code is loaded. At least, nothing is stated about that at the CLJS compiler options page or at the GCC optimizations page.
And yet, shadow-cljs creates a single file with :none
optimizations as well, so it works just fine for development.
uhm it didn't actually work anyway
well I'll switch to shadow this project as well at some point
but would be nice to at least just make sure they are all cached
which would make it just disk reads
I want to use SignalR with a clojurescript app. And I have gotten it to work like this:
1. npm install @microsoft/signalr
2. Copy signalr.js from node_modules/@microsoft/signalr/dist/browser
to resources/public/js/lib/signalr
3. In index.html: <script src="js/lib/signalr/signalr.js"></script>
4. In cljs file: (new js/signalR.HubConnectionBuilder)
etc.
Is there a better way to access signalR, preferably using :require
? And preferrably without copying from node_modules. I'm using the default project created by lein new re-frame <name>
not sure if that template uses shadow-cljs by default? you can just (:require ["@microsoft/signalr" :as signalr])
if you use shadow-cljs
@juri yeah, take a look at https://shadow-cljs.github.io/docs/UsersGuide.html#js-deps (vanilla cljs also support it, by other methods)
I have a code splitting question re: dead-code elimination. If I split into module A and module B, I'll end up with a cljs_base.js
, plus an A.js
and a B.js
. Does the cljs_base.js
have all of Clojurescript, or would an advanced compile trim it down to only the parts called by module A and module B?
further I think I'm understanding this to mean if only module A uses eg. cljs.core/map
then map
ends up in module A, not cljs_base.js
O_o https://clojurescript.org/news/2017-07-10-code-splitting#_cross_module_code_motion
technically correct, but that also means that module B doesn’t use anything in cljs.core
that calls map
, which isn’t usually the case
IME the majority of cljs.core
gets included and shared between modules, since so much code relies on code in cljs.core
, and it’s pretty self referential
Has anybody tried to get ClojureScript compiling down to non-GCC JS? Discussions above re code splitting, tree shaking etc makes me suspect we might benefit from being able to use Webpack