This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-09-01
Channels
- # aleph (7)
- # bangalore-clj (1)
- # beginners (89)
- # boot (5)
- # clara (21)
- # cljs-dev (2)
- # cljsrn (57)
- # clojure (58)
- # clojure-austin (1)
- # clojure-conj (1)
- # clojure-italy (5)
- # clojure-losangeles (3)
- # clojure-russia (4)
- # clojure-sanfrancisco (4)
- # clojure-spec (31)
- # clojure-uk (67)
- # clojurebridge (4)
- # clojurescript (56)
- # cursive (92)
- # data-science (4)
- # datomic (15)
- # emacs (23)
- # events (1)
- # fulcro (121)
- # gorilla (2)
- # jobs-discuss (1)
- # juxt (1)
- # lambdaisland (6)
- # lumo (13)
- # off-topic (11)
- # om (1)
- # onyx (17)
- # overtone (5)
- # parinfer (9)
- # planck (3)
- # re-frame (21)
- # reagent (95)
- # ring-swagger (7)
- # spacemacs (58)
- # vim (13)
- # yada (2)
@pesterhazy do you also got a solution for android with react-native-husk?
@mozinator i think it should work the same but I don't have any experience, the build script would need to be adapted I guess
looks like the react packager is executed through gradle. but maybe its possible to add some post execute hook
@pesterhazy thank you so much for the husk idea. was really pulling my hair out
a potentially less painful route is to use advance optimizations. You'll have to deal with externs though
@mozinator :advanced
is worth a try because externs can likely be dealt with by simply putting [react-native-externs "0.1.0"]
on your classpath
@mfikes thanks, going to check it out
saw that the new re-natal template has it added
3MB bundle with advanced instead of 6.7MB
@mozinator On iOS that can result in a speedup of 1.5 for launch speed. Perhaps that holds true for Android as well?
getting some strange errors and a crash when launching so can't tell yet
thanks! will try that out
also watch out for all instances of .-prop
and .method
in your code - you may have to replace them with goog.object/get
etc.
This is particularly true if you are using 3rd party components, which would not be covered in react-native-externs
3rd party components drawn from npm shouldn't be passed through GCC though, right?
RN components should be fine I think
ah wait you meant using those components
exactly, those are the places to check
Yeah, exactly. An alternative to resorting to goog.object
in those cases, of course, is to create your own externs for them (perhaps in a project-local file loaded via :externs
), and then to use .-prop
and .method
as you normally would for interop.
I suppose one theoretical advantage of this alternative is that, if things ever change where third party components can also pass through GCC, then your codebase proper is not “polluted” with code constructs that cater to calling external code, and you can selectively remove any externs you have set up.
thanks guys for the extensive information and I hope to use advanced compilation. but it looks like a 3MB bundle and advanced compilation is still too much for react-native-packager to handle
what is a typical bundle size that you have in production apps ?
Hmm @mozinator, my index.ios.js
is about 439K. Perhaps it gets to be 3MB due to stuff outside of ClojureScript?
(Although I guess I would be seeing the size after the packager… hmm. How do we see what gets passed to the pacakger?)
I am executing ncdu on my target directory and it looks like a couple of js files are huge
is are the files in target used for the prod-build / advanced-build ?
or is that just for figwheel / devmode ?
@mozinator I’m not intimately familiar with how ClojureScript compiles :advanced
, but I suspect it may copy JavaScript code into target while building, passing the JavaScript files representing ClojureScript namespaces to GCC. Those raw files definitely don’t end up directly in index.ios.js
—they are minimized. So the question perhaps has to do with your other stuff
@mozinator Perhaps you have a huge module listed in .re-natal
?
so I just removed my target dir. then did a lein prod-build and it looks like files in target are generated. so my guess is that those files will be used in the bundle.
its not reasonable in size, 3MB. but I figured out what happened. I am using this tool called clairvoyant which are macro's that add make it possible to trace all function calls in the system. And apparently they are still macroexpanded in production build mode
clairvoyant macro's add a lot of metadata to all functions
In your index.android.js
there may be calls to require
—the packager will scan for those calls, and that will cause extra stuff to be bundled
when using clairvoyant in combination with re-frame subscriptions and events the amount of added code is not a lot
but in case of user interface components the amount of extra added code is huge
@mozinator you could try setting goog/DEBUG to false and enabling elide-asserts to see if that helps
It would be interesting if Clairvoyant expanded into ClojureScript code that was guarded with goog/DEBUG
or its own goog-define
to disable it completely.
I suspect that I am at fault here. I made some macro's on top of clairvoyant which could be the cause of the issue
clairvoyant has a goog define, which toggles the macro
Oh, @mozinator It looks like Clairvoyant honors *assert*
, so Paulus' suggestion of :elide-asserts
may be sufficient
(You may want to just have :elide-asserts true
in your prod compiler options anyways.)
react-navigation is a popular option
@sllyq the cljs-react-navigation library that wraps react-navigation and provides reframe handlers is a godsend