Fork me on GitHub
#cljsrn
<
2017-09-01
>
mozinator212:09:59

@pesterhazy do you also got a solution for android with react-native-husk?

pesterhazy12:09:20

@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

mozinator212:09:09

looks like the react packager is executed through gradle. but maybe its possible to add some post execute hook

mozinator213:09:33

@pesterhazy thank you so much for the husk idea. was really pulling my hair out

pesterhazy13:09:09

a potentially less painful route is to use advance optimizations. You'll have to deal with externs though

mfikes13:09:35

@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

mozinator213:09:05

@mfikes thanks, going to check it out

mozinator213:09:18

saw that the new re-natal template has it added

mfikes13:09:29

Ahh, right, forgot about that 🙂

mozinator214:09:29

3MB bundle with advanced instead of 6.7MB

mfikes14:09:59

@mozinator On iOS that can result in a speedup of 1.5 for launch speed. Perhaps that holds true for Android as well?

mfikes14:09:24

(Guessing JavaScriptCore behaves roughly the same on both platforms.)

mozinator214:09:46

getting some strange errors and a crash when launching so can't tell yet

mfikes14:09:10

Ahh, :pseudo-names would be the first thing I would try

mozinator214:09:08

thanks! will try that out

pesterhazy14:09:21

also watch out for all instances of .-prop and .method in your code - you may have to replace them with goog.object/get etc.

mfikes14:09:31

This is particularly true if you are using 3rd party components, which would not be covered in react-native-externs

pesterhazy14:09:28

3rd party components drawn from npm shouldn't be passed through GCC though, right?

pesterhazy14:09:49

RN components should be fine I think

pesterhazy14:09:05

ah wait you meant using those components

pesterhazy14:09:19

exactly, those are the places to check

mfikes14:09:04

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.

mfikes14:09:22

Following that style, I suppose goog.object is relegated to accessing data, not APIs.

mozinator214:09:36

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

mozinator215:09:08

what is a typical bundle size that you have in production apps ?

mfikes15:09:08

Hmm @mozinator, my index.ios.js is about 439K. Perhaps it gets to be 3MB due to stuff outside of ClojureScript?

mfikes15:09:33

Let me fire things up and pull the whole concatenated bundle to see…

mfikes15:09:42

(Although I guess I would be seeing the size after the packager… hmm. How do we see what gets passed to the pacakger?)

mozinator215:09:47

I am executing ncdu on my target directory and it looks like a couple of js files are huge

mozinator215:09:37

is are the files in target used for the prod-build / advanced-build ?

mozinator215:09:54

or is that just for figwheel / devmode ?

mfikes15:09:22

@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

mfikes15:09:35

@mozinator Perhaps you have a huge module listed in .re-natal?

mozinator215:09:34

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.

mfikes15:09:58

Is your index.android.js reasonable in size?

mozinator215:09:20

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

mozinator215:09:31

clairvoyant macro's add a lot of metadata to all functions

mfikes15:09:41

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

mfikes15:09:13

Oh… I see. Yeah a 3MB index.android.js would do it.

mfikes15:09:43

Interesting. Joel knows his stuff. Don’t see anything on Clairvoyant on :advanced.

mfikes15:09:05

Seems like you would need to manually eradicate it from your code.

mozinator215:09:57

when using clairvoyant in combination with re-frame subscriptions and events the amount of added code is not a lot

mozinator215:09:12

but in case of user interface components the amount of extra added code is huge

pesterhazy16:09:34

@mozinator you could try setting goog/DEBUG to false and enabling elide-asserts to see if that helps

mfikes16:09:31

Looks like re-natal only takes care of the first by default

mfikes16:09:53

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.

mozinator216:09:26

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

mozinator216:09:53

clairvoyant has a goog define, which toggles the macro

mfikes16:09:17

Ahh, perhaps you can honor the same goog define

mfikes16:09:23

(In your macros)

mfikes16:09:34

Oh, @mozinator It looks like Clairvoyant honors *assert*, so Paulus' suggestion of :elide-asserts may be sufficient

mfikes16:09:56

(You may want to just have :elide-asserts true in your prod compiler options anyways.)

sllyq21:09:06

What's the most popular way to do routing in cljsrn? (I'm using re-frame)

mozinator221:09:36

react-navigation is a popular option

danielneal22:09:40

@sllyq the cljs-react-navigation library that wraps react-navigation and provides reframe handlers is a godsend