Fork me on GitHub

I have to develop on an 11 inch macbook. If I hit save, figwheel needs 20 seconds to refresh my app lol


oh looks like I didn't clean up my app-state correctly and kept adding into it. Now my app is at 16GB memory - that explains things


I'm on similar hardware and the example up is quite fast, @dvcrn


I have too many RAM hogs. - chrome (required for debugging) - react packager - figwheel / java - xcode - iOS simulator connected to xcode - Atom (running another chromium instance)


ah not to forget, slack of course also runs a own chromium instance 😛


xcode is a big one


hoping to get xcode out of the equation eventually (just run the app from the command line)


xcode eats less memory for me than slack


They should seriously think about optimizing electron to use one system wide chromium installation. 3 separate one for editor, chat and browser is a little much


I use slack in a tab in chrome


@artemyarulin: Just wanted to write couple of sentences to clear out my goals with re-natal (they might be not met fully). 1. Super easy bootstrapping for RN noobs like me. I had immediate success with natal when I wanted to try out RN with CLJS. It was super easy to start, and I liked it very much. At the time I was not able to find any lein template which does that for me, and unfortunately I did not know boot, so natal was a natural favorite. 2. Support development for both iOS and android. Unfortunately natal was only for iOS (though it has a goal of supporting android) and I wanted to create an app for both platforms. But could not find any tested/ready to use template for that. 3. (Selfish) provide ready to go example with Reagent + re-frame, because I liked it so much for the web, and that’s it. 4. Abstract away the problems of making figwheel work with RN. I'd like to keep it this way that figwheel related stuff is out of application codebase, because this is just a dev setup and IMO it should be hidden, but it has to be reliable. As a developer, I want to focus only on my production CLJS code and do as little as possible things for having good development experience. So, in fact, I do not think re-natal attempts to abstract away from RN itself, at least not in code. The template even does not include any wrappers for stock RN components, because I think each dev has its own perference on that. But, on the other hand, if there is some common action, which is annoying (like restarting RN packager, or whatever) and can be automated, I think it is a good thing that development tool of your choice has an ability to make that less annoying. Unless you like to be annoyed, the you can do it manually. That are my thougths, thanks for reading simple_smile


@drapanjanas: Thanks for explanation. Looks like I just have a different vision and a story: I came from RN and mobile development and for me it’s not a problem to open Xcode and compile things there, run packager manually and so on.


on the other hand if there would be not difference between our tools - there would be no reason to do it simple_smile


Yes, I agree, I first kinda thought of contributing to natal the Reagent+re-frame interface, but then I adopted figwheel approach, and I realized that having all that support in single project is a bit too much so I just left it this way. So there are difference in currently available tools and it is good to have them separate as aternatives!


Hm, on a Clojure Remote there gonna be one talk about RN


Don’t know if Jearvon Dharrie is here


from the description he’s gonna talk about RN + Ambly


Has anyone worked on getting ClojureScript source maps working with the React Native packager?


(I’m using Figwheel and loading the outputted JavaScript asynchronously)


scttnlsn: took a look at it today, we should be able to squeeze it somewhere in the transformer


scttnlsn: are you using boot-react-native as a starting point or made something yourself?


@jellea: Something I made myself a while ago (it was heavily inspired by


It just fetches the JS and evals it


The source map filenames are in the output JS but I don’t think RN would know about them


Looks like the packager inlines them all in the bundle?


source map could be possible only with boot-react-native approach


I’ll check it out


should be as easy as setting source maps for the transformer


currently too busy with organising ClojureBridge otherwise I would pick it up simple_smile


having source maps there would be awesome


in boot-react-native, I mean


@scttnlsn: I started integrating source map support but did not finish it. I suspect that RN expects the actual source map contents, not the filename as I've set it up in the transformer. I've added an issue if you are interested in looking at it - otherwise I'll also have a look at it later this week.