Fork me on GitHub
#cljsrn
<
2016-01-19
>
dvcrn09:01:22

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

dvcrn09:01:55

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

pesterhazy09:01:29

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

dvcrn09:01:22

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)

dvcrn09:01:16

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

pesterhazy09:01:28

xcode is a big one

pesterhazy09:01:08

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

dvcrn09:01:20

xcode eats less memory for me than slack

dvcrn09:01:06

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

pesterhazy09:01:51

I use slack in a tab in chrome

drapanjanas14:01:55

@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

artemyarulin15:01:46

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

artemyarulin15:01:27

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

drapanjanas15:01:24

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!

artemyarulin20:01:13

Hm, on a Clojure Remote there gonna be one talk about RN http://clojureremote.com/speakers/#dharrie

artemyarulin20:01:51

Don’t know if Jearvon Dharrie is here

artemyarulin20:01:13

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

scttnlsn20:01:57

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

scttnlsn20:01:21

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

jellea20:01:22

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

jellea20:01:19

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

scttnlsn20:01:10

@jellea: Something I made myself a while ago (it was heavily inspired by https://github.com/decker405/figwheel-react-native)

scttnlsn20:01:00

It just fetches the JS and evals it

scttnlsn20:01:16

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

scttnlsn20:01:36

Looks like the packager inlines them all in the bundle?

artemyarulin20:01:47

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

scttnlsn20:01:56

I’ll check it out

jellea20:01:43

should be as easy as setting source maps for the transformer

jellea20:01:16

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

pesterhazy20:01:29

having source maps there would be awesome

pesterhazy20:01:39

in boot-react-native, I mean

mjmeintjes23:01:41

@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 https://github.com/mjmeintjes/boot-react-native/issues/23 if you are interested in looking at it - otherwise I'll also have a look at it later this week.