Fork me on GitHub
#cljsrn
<
2018-04-06
>
vikeri12:04:50

Having problems with the metro bundler failing on out of memory issues when building the prod version. Would prefer not to use advanced build if possible, only simple. What are people using nowadays to compile? Tried ignoring with .babelrc but to no avail…

vikeri12:04:34

I know @pesterhazy and @jeaye have been working on this previously. What are you guys doing atm?

mfikes12:04:16

@vikeri I’ve gone with :advanced because the reduction in app launch latency was substantial compared to :simple for the app I was working on at the time

mfikes12:04:53

@pesterhazy For now, I’ve written unit tests that test without using React Native. In fact I found that I had to go farther than your safe-adapt-react-class suggestion and not even :require any re-frame / Reagent namespaces as that would trigger a fault with respect to js/React not being available. (I just went with the pattern of two different source paths for the small amount of code where that mattered.)

vikeri13:04:51

@mfikes ok that's very nice. I'm just massively dreading the externs for a full project where no consideration about externs has been taken...

pesterhazy14:04:04

It works with simple and advanced compilation

pesterhazy14:04:26

Although it may not be necessary to the same degree for adv comp because of the smaller bundle sizes

pesterhazy14:04:16

re-natal-husk works well, but it's a hack obviously

pesterhazy14:04:00

@mfikes, that makes sense. As an alternative you could try sticking something like this in front of your bundle: window.React=require("react") and add a package.json

vikeri14:04:33

@pesterhazy Sweet, I’d love to not use advanced yet. I’ll try it straight away

pesterhazy14:04:15

or even window.React={} 🙂

vikeri14:04:30

@pesterhazy Does it work with Android as well?

pesterhazy14:04:00

Haven't tried Android. The general approach should work, but you'd need to integrate it with the tooling (gradle?)

vikeri14:04:21

Ok, yeah the tooling is a bit more obscure in Android

pesterhazy14:04:16

More obscure than XCode? An impressive feat

vikeri14:04:17

Haha yeah, for iOS you run the react-native-xcode or whatever it’s called. But in Android you run some dynamically generated gradle task that is ungreppable…

vikeri14:04:03

@mfikes A question about advanced, does it understand for example promises or other “RN-js” flavor features? We’re using them straight in cljs with .then and .catch but that’s not valid ES3 of course…

pesterhazy14:04:51

why is that not valid ES3?

vikeri16:04:20

True, my brain betrayed me

pesterhazy14:04:09

(and we're targetting ES5 at worst, not ES3, right?)

jeaye16:04:14

@vikeri We used :advanced and it's essential for getting through babel without other workarounds.

jeaye16:04:47

The RN folks kept saying "just talk to the metro folks about it and it'll be fixed." My latest ticket was here: https://github.com/facebook/metro/issues/111

jeaye16:04:42

There are a few more in that repo, for the same thing. In short, they're not gonna do anything about it and have admitted that the file size -> execution time relationship is non-linear.

vikeri16:04:27

Yuck, ok. I guess I'll have to get my externs in order then.

jeaye17:04:44

@vikeri We don't do any extern nonsense, actually.

jeaye17:04:10

1. Use cljs-oops 2. Enable :infer-externs

jeaye17:04:30

Everything has "just worked" after that.

jeaye17:04:35

Everybody using ClojureScript should be using cljs-oops.

👍 2
vikeri18:04:11

@jeaye wow that hasn't been my experience at all. But I haven't used cljs-oops. Will check it out. Thanks!

danielneal18:04:03

❤️ cljs-oops

mfikes19:04:30

If I re-natal set-figwheel-port 3550 and then re-natal use-figwheel, when I do (start-figwheel "ios") in my Cursive REPL, it still starts on 3449. Anyone know what the trick might be?

mfikes19:04:39

I’ve added an enhancement ticket where we can improve the documentation around setting the Figwheel port when using re-natal https://github.com/drapanjanas/re-natal/issues/177