This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-12
Channels
- # bangalore-clj (4)
- # beginners (77)
- # boot (71)
- # cider (10)
- # clara (1)
- # cljs-dev (52)
- # cljsjs (28)
- # cljsrn (1)
- # clojure (390)
- # clojure-dev (5)
- # clojure-india (1)
- # clojure-italy (5)
- # clojure-nl (24)
- # clojure-poland (4)
- # clojure-russia (123)
- # clojure-spec (71)
- # clojure-taiwan (2)
- # clojure-uk (8)
- # clojurescript (236)
- # core-matrix (6)
- # cursive (19)
- # datomic (16)
- # defnpodcast (2)
- # editors (1)
- # emacs (36)
- # garden (2)
- # hoplon (5)
- # jobs (1)
- # jobs-discuss (10)
- # juxt (47)
- # luminus (4)
- # lumo (6)
- # off-topic (207)
- # om (1)
- # onyx (20)
- # pedestal (40)
- # perun (2)
- # re-frame (8)
- # reagent (48)
- # ring (2)
- # ring-swagger (2)
- # specter (13)
- # unrepl (89)
- # vim (6)
@anmonteiro finally 🙂 I’ll cut a release just for this probably later today
@darwin the problem is that Closure doesn't really understand the CLJS immutable collections. so at some point it will give up optimizing them
I’m probably going to leave that issue open, maybe will play with an alternative implementation of cljs.core.PersistentHashMap.fromArrays
just out of curiosity.
once, I was able to reimplement a core method to be less dynamic and understood by DCE: https://github.com/binaryage/cljs-devtools/blob/master/src/lib/devtools/prefs.cljs#L5-L7
@thheller I’m going to fix all my code to use lazy config maps initializations - like you proposed. And then use macros to generate my ns-forms. Will check compiler options and in advanced mode I won’t require cljs.pprint
. In my code I will dynamically check for its presence and use non-formatted code path. Something along those lines.
anyone have any experience with writing closure compiler plugins? I saw someone wrote one for react components http://blog.persistent.info/2015/05/teaching-closure-compiler-about-react.html and ever since I have wondered about the possibilities of teaching Closure more about generated cljs
@darwin seems to me you are trying to optimize something the user really needs to take care of? just make :preloads
the only safe recommended path
I was thinking in terms of performance (maybe lowering maps down to struct js objects), but perhaps DCE would be easier and more fruitful
@favila I have written two, one which I rely on https://github.com/thheller/shadow-build/blob/master/src/java/com/google/javascript/jscomp/ReplaceCLJSConstants.java
you could maybe write a pass that removed the entire defmulti
if it is never called anywhere but I think that would be hard
wrote another pass recently to remove (def x (some-side-effecting-fn))
where closure would strip the def
but leave the (some-side-effecting-fn)
which produces something that isn't useable without the result
you give it a #{"my.super.side_effect_fn"}
set and if it finds calls to that fn that aren't assigned to anything it will remove it
(cljs/add-closure-configurator
(fn [cc co]
(RemoveNameDependentCalls/install cc co #{"my.foo.fn"})
))
https://github.com/thheller/shadow-build/blob/master/src/main/shadow/cljs/build.clj#L2399-L2400
other than https://github.com/google/closure-compiler/wiki/Writing-Compiler-Pass and other people's sample code I've never found any documentation
adding to CompilerOptions is still better than what the wiki talks about (editing DefaultPassConfig.java)
well depends on when you need your pass to run, if specifically need to be in between two things
@dnolen FWIW we’ve been using the new compiler release since yesterday in Prod
in case you needed a sanity check
@anmonteiro cool, yeah will cut a release later today
@thheller this looks like a reasonable solution for now: https://github.com/binaryage/cljs-devtools/commit/30a3497f7fd62230348a11dcb22019b40b6e4f80#diff-87182341560ecab47ddb34421cbb1efb