Fork me on GitHub
#cljsrn
<
2015-12-28
>
artemyarulin08:12:28

Author of boot-react-native replied me about nrepl support (yes) and mentioned that he will add more documentation about his approach: https://github.com/mjmeintjes/boot-react-native/issues/1 I’ll play a bit with his project after the NY holidays, but looks really cool

artemyarulin08:12:43

and no - WritingCompilerPass is not a way 😛

sridatta08:12:47

hey folks, I’ve been researching this topic quite heavily for the past week and recognize some familiar names from github! one thought: could it be possible to hook into the cljs compiler to have a react-native target?

sridatta08:12:14

I see there’s a {:target :nodejs} option which uses a different require system and generates a different main.js

sridatta08:12:33

and those are the two things that a lot of the cljsrn templates end up shimming/working around

artemyarulin09:12:38

I’ve been thinking about that, but why exactly? ReactNative using simple JS and all the workaround that we heavily do here is actually about repl support|packager and the way how we can re-use existing frameworks (om/reagent) with react.

artemyarulin09:12:53

At the end there is nothing in CLJS itself actually

sridatta09:12:34

yeah its true that cljs itself has nothing to do with it

sridatta09:12:56

I just see a lot of workarounds that either circumvent the build system (load modules via figwheel) or transform files/directory structure to convert what cljs emits to something react-packager can deal with

sridatta09:12:10

and those happen out of band from the build system

sridatta09:12:48

actually, reading the above, it looks like boot-react-native is the cleanest solution so far. integrates a lot of the hacks into the build process

artemyarulin09:12:02

Yeap, with boot-react-native I see no issues in a long run. There are couple of hacks, but they are quite minimal

artemyarulin09:12:28

actually I’m still not sure about dropping existing figwheel-react-native solution - figwheel is much more mature comparing to rn packager (ability to specify ^:figwheel-reload-never or smth like that)

sridatta09:12:48

I don’t see a clear way to bundle the JS for production use though?

artemyarulin09:12:59

this is solved

artemyarulin09:12:49

Basically there is no problem around it - you just compile the project (exclude browser version of react if you are using om/reagent), add externs. Then run react-native packager to generate bundle. Here example of project https://github.com/artemyarulin/om-next-cross-platform-template/blob/master/resources/leiningen/new/om_next_cross_platform/project.clj And release build runs like this:

lein with-profile mobile cljsbuild once release) && react-native bundle --entry-file mobile.release.js --bundle-output om-next-ios-pure/js/main.jsbundle --platform ios

artemyarulin09:12:43

react-native bundle creation then just look for all (js/require [module-name]) and concat the source to the bandle

sridatta09:12:59

ah got it, very useful to know

artemyarulin09:12:53

yeah, as you can see with release build there are no hacks at all - just CLJS -> JS and then react-native bundle command. All the workaround we need only for the development mode

artemyarulin09:12:53

(for anybody - this lein template is work in progress and doesn’t work currently, although readme says different thing :P)

johannjohann20:12:22

nice this story is definitely maturing simple_smile

johannjohann20:12:08

i am gonna do a deeper dive today because my work kind of also needs a similiar solution--but i think having the module interop stuff exist in the cljs build process through leveraging google closure can give us the most foundational approach

artemyarulin20:12:59

@johannjohann: do you use RN for work already?

johannjohann20:12:46

the plan is to use it--im still doing design docs

artemyarulin21:12:20

Really awesome answer from @mjmeintjes about his boot-react-native: https://github.com/mjmeintjes/boot-react-native/issues/1#issuecomment-167656801 Looks like if we decided to migrate his approach to lein it will be more difficult, comparing to the existing boot version

johannjohann21:12:07

yeah, the task stuff in boot is pretty great

johannjohann21:12:30

and the composition of features is great

johannjohann21:12:04

@mjmeintjes: hey thanks for the cool interop solution :dancer:

artemyarulin21:12:21

yeah, I guess I should finally sit and play with a boot. lein project became quite big for mobile project, with all those profiles, different deps, multiple cljsbuilds and so on

johannjohann21:12:04

the abstractions are strong, so its a lot faster to have fun imo 😄

johannjohann21:12:32

the equivalent of 'tasks' in lein require macro usage which is... 😢

mjmeintjes22:12:30

Yeah, I've found boot to be really well designed and a lot more fun to work with/extend.

artemyarulin22:12:47

yeah, I would add boot to my NY resolution simple_smile

johannjohann22:12:28

the fileset concept is 😮

adamfrey22:12:55

count me as someone who will be very happy if the cljsrn community moves towards boot 👍

artemyarulin22:12:21

well, now with boot-react-native we have a reason yeah.

johannjohann22:12:57

@mjmeintjes: i understand this stuff is kinda gross (lol) but heres google closure code that rewrites commonjs requirements

johannjohann22:12:55

could potentially add a compiler pass that lines up the dependencies maybe

donmullen22:12:32

I’d also love to see cljsrn community embrace boot — long term much better solution. And @seancorfield indicted he might take a crack at boot-template - which the primary missing boot feature.

artemyarulin22:12:59

oh, boot doesn’t have a templates like lein do?

donmullen22:12:23

No - most boot folks are still using lein to create templates.

donmullen22:12:25

All the pieces are there - don’t think it will be especially hard — and there has been recent active discussion on approaches.

mjmeintjes22:12:04

My personal opinion is that there is a lot less need for templating when you are using boot - less code and much easier to understand than lein project.clj

artemyarulin22:12:34

well - for mobile development I really like template idea

donmullen22:12:14

I like the idea of templates especially to make it easier for people new to clojure / reactNative / boot — to get something going quickly.

artemyarulin22:12:07

many folks coming with CLJS experience only and setup an environment|repl should be handled automatically

mjmeintjes22:12:30

But should the templating be part of the build system or a separate library?

artemyarulin22:12:02

dunno. Naked template doesn’t make much sense (for me IMHO) and we should probably create different templates for om-next/reagent/etc.

mjmeintjes22:12:25

My problem with templates comes from when I started out with ClojureScript a few months ago - it seemed easy to just run the lein command to set up the project, but that left me with a project with lots of dependencies that I knew nothing about. It felt pretty intimidating when you've got all these dependencies in your project and you don't know how they are interacting and what they are doing. I think updated documentation is really important.

johannjohann22:12:44

parity with the react native experience would be a nice goal

artemyarulin22:12:57

makes sense yeah

johannjohann22:12:07

i dont know if anything is going to resolve the moving parts pain of the cljs experience, but maybe we can aim to make sure when something does break, the dev has a clear signal of what isnt working as expected, to avoid deep dives

artemyarulin22:12:45

but at the same time we have to have some abstraction level, otherwise we’ll have to write:

(.createClass react-native (js-obj {“render” (.createElement react-native (.-Text react-native) nil “HelloWorld”)}))

johannjohann22:12:27

looks clean to me 😛

johannjohann22:12:33

@mjmeintjes am i right in assuming that your method also allows cljs source maps to work when you debug?

mjmeintjes22:12:13

I agree, and think we should add cljs abstractions over React Native to enable cljs developers to build mobile apps without having to understand too much about React Native itself. I spent too many hours reading React Native Packager source code, which is what I'm trying to abstract away using boot-react-native. Same thinking can probably be applied to other areas of using RN.

mjmeintjes22:12:14

@johannjohann: Not sure about that - I can't see any technical reasons for it not working, but I haven't tried that at all. I generally prefer to debug very infrequently, and when I do I prefer to look at the JS.

johannjohann22:12:39

yeah--with a browser repl, reload on save, and source maps working

johannjohann22:12:56

the cljs experience is on par with the js in react native :thumbsup:

artemyarulin22:12:20

@mjmeintjes: I’m working on exactly that - https://github.com/artemyarulin/ktoa/blob/master/src/ktoa/components.cljc, just a set of wrappers without any additional logic to avoid nasty interop

johannjohann22:12:15

someone wrote this library

johannjohann22:12:19

that scrapes the react native docs

johannjohann22:12:25

and generates cljs wrappers from it lol

johannjohann22:12:28

it was amazing let me find it

mjmeintjes22:12:32

@artemyarulin: ktoa looks cool, and exactly what I'm talking about when it comes to abstracting away implementation details of RN.

johannjohann22:12:37

same guy who wrote re-natal

johannjohann22:12:58

excuse me, natal

johannjohann22:12:39

confusingly named but still pretty badass

artemyarulin22:12:52

everything generated from the docs, indeed badass simple_smile

johannjohann22:12:17

strategies like this in general is the right way to go with react native still maturing etc

artemyarulin22:12:34

not sure about that - take Alert class for example: it has only one static method Alert.alert which should be exposed directly, without any additional wrappers in the middle

artemyarulin22:12:20

or maybe not - dunno