This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-31
Channels
- # beginners (9)
- # boot (38)
- # cider (7)
- # cljs-dev (181)
- # cljsrn (49)
- # clojure (136)
- # clojure-italy (44)
- # clojure-losangeles (1)
- # clojure-news (1)
- # clojure-russia (3)
- # clojure-sanfrancisco (1)
- # clojure-serbia (2)
- # clojure-spec (28)
- # clojure-uk (41)
- # clojure-ukraine (1)
- # clojurescript (103)
- # core-async (6)
- # core-logic (46)
- # cursive (5)
- # data-science (8)
- # datascript (6)
- # datomic (5)
- # emacs (35)
- # events (3)
- # jobs (2)
- # jobs-rus (2)
- # juxt (6)
- # lumo (7)
- # off-topic (101)
- # om (6)
- # onyx (6)
- # parinfer (38)
- # pedestal (5)
- # perun (1)
- # planck (4)
- # protorepl (4)
- # re-frame (62)
- # reagent (20)
- # remote-jobs (1)
- # ring-swagger (1)
- # spacemacs (16)
- # unrepl (43)
- # vim (13)
@jeaye just tried out your repo and was able to repro the problem TimeoutError: transforming /Users/pe/prg/react-native-packager-bug/index.android.js took longer than 301 seconds.
Hi @pesterhazy, @jeaye:
I just caught myself up on the #cljsrn chat history for the last couple of days, and the timing of this is pretty funny.
I used to experience the same type of timeout/memory issues that you have been talking about, but I made some terrible hacks to avoid them when I was on RN 0.40.0
. Last week I went through the upgrade process from RN 0.40.0
-> 0.46.4
process for the ClojureScript + React Native app that I work on, which (as expected...) broke my release bundling process again.
So, after upgrading my hacky setup, I wrote a rough post (http://austinbirch.co.uk/2017/07/28/clojurescript-and-react-native-bundling-for-release-with-advanced-optimisations.html) about how I hacked my way around the issues for future reference, and mostly finished it up last weekend. I’ve published it in its current state just now in case there’s anything useful in there that can save you time/validate assumptions etc.
@pesterhazy, I think your re-natal-husk
idea is much much better than the setup I have, but you still might have trouble getting source maps working with it? If so, you might want to take a look at the first part of my approach (custom transfomer); it might help you to come up with something workable for source maps.
I really wish I had had waited until this week to start upgrading RN so that I could have started with your approach - it seems pretty promising to me.
@austinbirch very interesting thanks
will read the blog post later today. good point about the source maps. Out of curiosity, what do you need the source maps for in Release builds?
on the larger point, I think we really need to break this cycle of packager updates breaking prod builds, again and again
ideally the fix should go into metro-bundler directly, but I'm not holding my breath given hoe reponsive their devs have been in the past
the 2nd best option would be a reliable workaround, which I think the react-native-husk experiment might prove to be
hello, how would one go about implementing deep linking in clojure, as in: https://medium.com/react-native-training/deep-linking-your-react-native-app-d87c39a1ad5e
@pesterhazy
> Out of curiosity, what do you need the source maps for in Release builds?
We had some trouble using :simple
optimizations. The final main.jsbundle
was massive (we have quite a large project, I suppose) so the app did take a long time to start in release. We were also were getting some iOS OOM issues too. Oh, and builds created with :advanced
seemed more responsive UI-wise for us too.
Compiling with :advanced
optimisations solved those problems (much smaller bundle, less time taken for RN to load it, no OOM issues), but meant that any exceptions that occured during use were pretty annoying to debug. The stacktraces sent to Sentry listed columns/lines from main.jsbundle
, and obviously all of the names were mangled & minified too. Recovering source maps gives us original file+line+column in Sentry, and inline original-CLJS for the context around those stack traces as well.
Agree with the rest of what you’ve said above. I was hoping that as other users of compile-to-JS languages had issues the packager would grow to be able to work with that model, but that doesn’t seem to have happened yet. I did consider figuring out a PR for metro-bundler, but without any documentation it’s pretty hard to understand.
I’m continuing to dig into why NativeModules
is empty for iOS, unless debugging remotely with Chrome. I found that it is also empty when doing prod builds, which seems to exclude the re-natal
Figwheel bridging from being a cause. I’ll share if I figure out what is causing this.
@mfikes I'm pretty sure I've used NativeModules from re-natal in both figwheel and prod builds
@pesterhazy Cool. Perhaps something regressed with later RN versions
Could it be that it's a magical object that only works right of you access a property but you can't enumerate keys?
Maybe the module was there all along but hidden
@pesterhazy You appear to be correct on the “magical object” theory.
Hidden in plain sight
I’ve updated the README showing things working now: https://github.com/mfikes/use-native-code
Thank-you @pesterhazy !
@mfikes no problem
What would be the standard way to handle different api urls when in dev vs prod for cljs? I’m fairly newer to front end so I’m not sure if this is even the right question.
the RN packager sets the js/__DEV__
var
I use
(defn dev? [] (and (exists? js/__DEV__) js/__DEV__))
so if you're compiling a bundle for Release configuration (xcode/iOS), (dev?)
will be false, and true in Debug configurations
note that you can nicely run Release builds in the simulator: run-ios --configuration Release
@austinbirch just had a chance to read your blog, nice work
@pesterhazy thanks. Still want to clear some of it up (usefulness is understanding why the packager tweaks are needed, not the implementation) but hopefully it won't be relevant for much longer!
@jeaye I've stolen your code generator: https://github.com/pesterhazy/re-natal-husk/blob/master/src/quax/lots.cljs
I've also simplified the transformation step: https://github.com/pesterhazy/re-natal-husk/blob/master/husk-react-native-xcode.sh#L103
@pesterhazy hehe, what a silly macro.
silly but useful 🙂
the husk approach seems to work for me, but it would be great if someone else could try it as well
I still have 2 todos
it'd be great to have a better way to use the script. Currently you need to change your xcode config/ Android build config to use a different script
also it'd be great to auto-generate this file from .re-natal: https://github.com/pesterhazy/re-natal-husk/blob/master/husk-requires.js
I've brought it up with my guy and we think it's a good workaround. Currently, :advanced
is both working around the timeout/OOM issues as well as giving us a smaller/faster bundle. For generating a non-prod APK, using :none
or :simple
, I think we'll go with your approach, but we don't yet have that need and are trying to meet some other deadlines.
yeah I know how it goes
:advanced
is great as well
my approach should have advantages with advanced comp too - much faster bundling step
but i know it doesn't matter so much as long as it finishes
Yep, agreed that it would be faster. You should add a comment to that RN ticket, for any CLJS users who hit that issue again and need this.
right, which ticket was that again?
Ok done
it's an itch i wanted to scratch for a long time