what do you guys use for logging? need to get some rudimentary logging done and can't find that much info. using re-natal

@kitofr: what are your requirements?

In cljs I mainly use a my.project.logging namespace like this:

(defn log [& s] (apply println s))

     (def debug (fn [& _])) ;; no-op for now
     (def info log)
     (def warn log)
     (def error log)

this basically just uses println, bute when a need arises for better logging, I'll be able to replace it with something more granular

you can also use something like this: https://gist.github.com/martinklepsch/b116442ad7f3b1f99fa1

(hat tip to @martinklepsch)

@shader: animations work just like in react-native proper

(def animated-view (r/adapt-react-class (.-View js/Animated))); you'll need to use js interop to use js/Animated.Value.

(set! js/Animated (.-Animated js/React))

ah, tnx

well... i just realised that I mainly need to configure my xcode-env to output things in a decent format

🙂

interesting, how do you do that?

when I look at my simulator log (`react-native log-ios`), I see a bunch of useless crap, besides the interesting app logs

a lot of noise essentially

XCode's debug window is better, but I really don't want to have XCode open all the time

how do you guys mix shared and platform specific code?

looking at luno exampe there's a lot of passing of functions or components that are platform specific into and out of shared code

thought that multimethods might make more sense

I'm curious about that

what kind of differences between ios and android are you thinking of?

well button for eaxmple

should be easy to add in a shared view also

but need to abstract away the platform differences in exact prop names etc.

@macroz: I use the env library and a macro like this:

(defmacro pcomp
  "Gets platform dependent component"
  [c]
  (symbol (str "pilloxa." env/PLATFORM ".components") c))

referencing the component is not exactly a problem but the slightly different usage

I use (def platform (.. js/React -Platform -OS))

I think buttons should not behave differently

a toolbar etc., those are platform specific

I'd like to share a bit more of my code but how does the shared code access the platform specific components in an abstracted manner

why not (defn toolbar [] (if (= "android" platform) [toolbar-android] [toolbar-ios])) ?

so you would implement a generic component library on top of the platform specific ones?

@macroz I do that

yup

react native tries hard to expose the platform specific stuff so you can get the UX perfect, not a hybrid experience

it's not write once, run anywhere, right? 🙂

a game, or some app with a lot of custom UX might get away with just having the same thing on all platforms but a "regular app" would not

well a lot of code can be shared

my problem is in the interaction between native and shared components

how specifically should I go about that

can you name an example?

let's say you wrap a text and like button inside a card list

text is probable shared

button is native

card probably native

scene should be shared

root is probably native

root needs to bootstrap the native experience

then it can add the shared scene

scene needs to display a list of cards but the card components are native

so how does the scene refer to the native components without depending on them?

those ifs pollute your code

same problem for the card and button

you only refer to the abstract components

the abstract component then include conditionals, yes, but that seems fine

there's a bunch of ways you can go about referring to the abstract components

for simple things I'd say a quick (when (android? ...) is fine here and there

and we all know that type case and ifs are bad, ok for a quick hack but tech debt

I don't agree about that, honestly

seems like the case for the components needs something more than the occasional hac

it's much easier to go overboard with multimethods etc as a premature abstraction

possibly

also because there is only ever going to be a number of platforms that you can count by your fingers

https://twitter.com/JefClaes/status/479938803038420992

I don't see multimethod as an abstraction in that sense

it's just one option

I'd only go down the garden path of picking a specific abstraction once you know much more about how the conditional paths in your app are going to look like

I don’t think that conditionals are that ugly of a hack, I will use it until I the code is so big that I can come up with some smarter way of doing it.

exactly, @vikeri

well I'm at that point now

writing components should be simple and not bloated with the ifs or passing native component constructors around

it's an interesting architecture topic

in these discussions I always tend towards the naive solution

and clojure offers many options for doing the thing

I think this kind of option is mostly static

i.e. if the set of options was dynamic and could be extended by someone else, I'd prefer multiple dispatch

now there really is going to be only 2 platforms for this app and never more

how would you use a multimethod?

use multimethod as the constructor for the component

what do you mean by constructor?

reagent fn?

[multimethod-function @platform {:my :args} and-something-else]

something like that

but since the set of platforms is not going to expand I think this is not the best possible solution

but also don't think it's the ifs

thought that maybe there are other cool options

might be an interesting topic for a blog post

platform also is not changed during runtime so subscription is not the way I think

important thing is that it's simple to reason about

so maybe in the very root component use dynamic scope and bind the ui components to their native implementations

then it is trivial to refer to them statically

why not just a simple global def, as in my example above?

as you say, the platform is static

I'll have to try and see

yeah the proof is in the pudding

please report back!

I'm getting to the point where I need to make these decisions myself

Yeah, very interesting. I think I will parametrize my builds with env so that I can have android/ios hardcoded in each js-bundle. Hopefully slightly better performance + I got some error just from having DatePickerIOS required when running in Android...

you can easily do (def date-picker-ios (when-not (android?) (js/require "date-picker-ios")))

by the way, has anyone come up with a nice solution for the "imports" used in RN? https://github.com/mjmeintjes/boot-react-native/blob/master/example/src/mattsum/simple_example/core.cljs#L20-L23

that seems like something a macro may help with

(rn-import view image text touchable-highlight)

yeah sure I'll report back

possibly this thing will be open source at some point

that'd be awesome

we need more cookbook-style cljsrn example code

yeah, but it's also difficult since everything is a moving target so the example code goes stale pretty quickly

yes and no

actually, most of the code we wrote 1 year ago still works exactly as it is

the tooling has changed quite a lot though

basic clojurescript and re-frame is quite stable indeed

yes and most of this also goes for react-native

yep

and the platforms themselves

there was a big change in 0.25 (react-dom/react-native split)

but mostly they are good about backward compatiblity

I'm pretty impressed with the RN team's work in general

(the RN packager is a different story)

yeah, it's just the small cuts that hurt a lot because they cost a lot of time compared to the ease of implementing stuff these days

and polish requires a lot of work, as always

agree

the thing is we can alleviate a lot of this by sharing workarounds, warnings and performance improvements

I feel that the community is very important in this "wild west" of cljsrn app dev

I see that the output of the dist task in boot-react-native seems to have global.__DEV__ = true. Can that be modified somehow?

@vikeri: I use https://gist.github.com/pesterhazy/d05170f45e10b6916206583f28b21cae

it's a hack, but it works

again, a github issue would be great so we can track the issue

Haha yet another scripting language introduced. Guess it was faster to script than a boot task? I'll file an issue. Also realized brn ignores :closure-defines will file an issue for that as well.

And how does the full release process looks like. What do I do with the created bundle?

hmm it shouldn't ignore closure-defines -- we use that option successfully

yeah, it was just a quick hack, easier to do in python

you need to add the js bundle to the app bundle (in xcode you can drag it into your project)

I'm sure the react-native guys have a way for that now, might be worth checking (I build my own bash script that runs in an xcode build phase)

I've implemented automatic patching of node_modules/react-native in master

the new task, patch-rn, is idempotent 🙂

>you need to add the js bundle to the app bundle (in xcode you can drag it into your project) As you are discussing other languages let me introduce Ruby and https://github.com/CocoaPods/Xcodeproj project, because it’s not enough

require 'xcodeproj'
project = Xcodeproj::Project.open('app.xcodeproj')
bundle = project.main_group.groups.first.files.first
project.targets.first.add_resources([bundle])  # RN default project doesn’t include js bundle in target
testTarget = project.targets[1]

# Dynamically add new test files to project
Dir["appTests/*.m"].select{ |f| 
  f != "appTests/appTests.m"
}.map{ |f|
  testTarget.add_file_references([project.new_file(f)])
}
project.save

I’m actually using this for testing RN + CLJS, so in case you need to do a lot of changes in xcodeproj often - consider this project

sick

so what's the right way to make a new app using boot-react-native? Is it just adding the two boot tasks mentioned in the readme?

it looks like there might be a lot of extra boiler plate required, based on the example app, but I'm not sure that forking boot-react-native to use it is the right idea either

right

yeah so a bit of logic in build.boot is required, and some other stuff, like https://github.com/mjmeintjes/boot-react-native/blob/master/example/app/init.js

your best bet at the moment is to copy SimpleExampleApp

however, we should start moving logic into boot-react-native proper, so that less boilerplate in apps is required

there's also https://github.com/jellea/react-native-boot-template but it hasn't been updated in a while

I hope @jellea will update it soon, once things settle down a bit with BRN

though using a project generator is also not a perfect solution, as you need to keep things updated as BRN changes