cljsrn 2017-05-16 | Slack Archive

seantempesta02:05:16

@gphilipp: The base ones? No. I have an example using the re-frame ones. I finally got around to packaging up my library with an example. It’s still rough, but I hope this helps. https://github.com/seantempesta/cljs-react-navigation

pesterhazy07:05:47

@carocad that's correct 🙂

carocad08:05:45

@pesterhazy but if it is like that then having the whole re-natal + figwheel would definitely be an overkill, wouldnt it? I mean I still need to see how does it all play in a real device but if react-native is able hot-reload the code without any funny business (like re-natal does) then this approach would be much more simple 🙂

pesterhazy08:05:02

the challengers are 1. fast turnaround and 2. keeping state in the app (e.g. respect defonce, rerender root)

carocad08:05:49

so far the first build takes significantly longer than with figwheel (I guess because cljs rebuild the whole file from scratch), but afterwards every save/compile command is usually compiled in less than a second. I still need to test the defonce behavior but I guess it shouldnt be affected since that is not a repl feature but a cljs one.

pesterhazy08:05:24

really curious what you'll find!

pesterhazy08:05:29

please report back

carocad08:05:27

@pesterhazy do you know why the repl + cljs auto build is usually not offered together? I dont understand if that is so simple to get from the cljs compiler, why are those two feature usually not found together (like in cljsbuild, lein noderepl, etc) beside figwheel.

pesterhazy09:05:23

not sure what you mean by together

pesterhazy09:05:40

figwheel does a ton of things in addition to just calling that function

pesterhazy09:05:03

however I agree there should be more awareness that getting a repl is actually pretty easy

thheller14:05:54

hey folks, I'm testing a new tool I made with react-native but an app generated with create-react-native-app gets extremely slow when generating the JS

thheller14:05:58

is that normal? are other solutions also slow?

thheller14:05:21

I suspect that its the react-native packager but don't know anything about it

gphilipp14:05:14

@seantempesta your repo is the perfect answer to my question, thx

seantempesta14:05:30

@gphilipp: Rad. Glad I could help. :)

pesterhazy14:05:06

@thheller how slow are we talking?

thheller14:05:42

2:39:28 PM: Finished building JavaScript bundle in 108191ms very

pesterhazy14:05:42

the packager is pretty slow. The first transpile step can take >60s. But not more than 2 minutes normally

thheller14:05:08

I think I figured it out, it runs the generated code through a whole bunch of babel transforms

thheller14:05:18

and not a single one is needed

thheller14:05:20

ah so it is normal. thought I was doing something wrong.

pesterhazy14:05:37

yeah I've experimented with disabling the babel transforms

pesterhazy14:05:43

never quite successful

thheller14:05:48

yeah doesn't seem to work

pesterhazy14:05:04

you can set up a .babelrc or something, but I haven't figured it out

pesterhazy14:05:20

the problem is transpiling the entire Google Closure library

pesterhazy14:05:33

it's a huge chunk

pesterhazy14:05:01

if you run the RN packager in production mode, it easily chokes on the it unless you manually give it more RAM to use

thheller14:05:01

nah its just cljs.core

pesterhazy14:05:42

give re-natal a try, it's reasonably fast

pesterhazy14:05:02

you can also precompile parts of the app with some trickery

pesterhazy14:05:11

then subsequent compiles are quick

thheller14:05:16

ok it works now

thheller14:05:51

just removed the "react-native" preset from .babelrc

pesterhazy14:05:12

maybe it's just because it's the second compile

pesterhazy14:05:27

try find "$TMPDIR" -depth 1 -name 'react-*' -delete to clear the cache

thheller14:05:29

just restarted the thing. does it cache somewhere?

thheller14:05:36

ah hehe

pesterhazy14:05:47

make sure you actually have a TMPDIR

pesterhazy14:05:03

stay safe 🙂

thheller14:05:44

so can you enable babel presets per directory or so?

thheller14:05:55

or are they always global?

pesterhazy14:05:13

don't know

thheller14:05:31

> Babel will look for a .babelrc in the current directory of the file being transpiled. If one does not exist, it will travel up the directory tree until it finds either a .babelrc, or a package.json with a "babel": {} hash within.

thheller14:05:45

lets see if it actually works that way 😉

pesterhazy14:05:43

in my experience the RN packager is pretty unreliable and largely undocumented

pesterhazy14:05:52

it's become slightly better recently

thheller14:05:32

hehe nope .. seems like once a preset is used all hope is lost

thheller14:05:25

yeah seems terrible ... well maybe another time

mv17:05:32

@pesterhazy println works great, thanks 🙂