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…

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

@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

@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.)

@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...

@vikeri, this approach works well for me: https://github.com/pesterhazy/re-natal-husk

It works with simple and advanced compilation

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

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

@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

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

or even window.React={} 🙂

@pesterhazy Does it work with Android as well?

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

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

More obscure than XCode? An impressive feat

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…

@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…

why is that not valid ES3?

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

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

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

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.

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

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

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

Everything has "just worked" after that.

Everybody using ClojureScript should be using cljs-oops.

🙂

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

❤️ cljs-oops

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?

@vikeri I assume https://github.com/google/closure-compiler/blob/master/externs/es6.js#L1225 takes care of .then and https://github.com/google/closure-compiler/blob/0a0a8ec45ab0df1f5d35bd2881a9dea2b4f7cceb/src/com/google/javascript/jscomp/DefaultExterns.java#L33-L34 ensures you get those externs, but I haven’t tried .then yet under :advanced

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