Why two core.cljs files ? about re-natal

[drapanjanas]

Indeed, in generated app, the core.cljs for android and ios has identical code. But when you start developing your app you will have different UI code for iOS and android. I do not really understand how you can have same code for both platforms.
Maybe you can elaborate what you mean or give an example?

[olivergg]

@drapanjanas Well, I think I've been misled by the name of the file, "core.cljs" .... It's more like a "view.cljs" ;)
But what about very simple UI ? A component like TouchableHighLight would be the same on both android and ios, wouldn't it ?

[drapanjanas]

Well, I guess, in super simple cases probably one could use only cross platform components. But it is clear that goal of ReactNative is not "write once - run everywhere".
But, I agree that in generated app most of code of core.cljs is definition of view. After all, it is a "hello world" app intended for experimentation with various platform specific components which you can try out right the in core.cljs and see how fighweel reloads your code.
It is left up to developer what other namespaces (shared or platform secific) he/she would like to create to move UI stuff out of core.cljs in a real app.
Have a look at this cross-platform example app I think it is a good and realistic example, which has some shared and platform specific code. Hope this helps.

[artemyarulin]

Addition to that: http://facebook.github.io/react-native/docs/platform-specific-code.html#content

Definitely it's not a RN goal to "write once - run everywhere", although you can (in runtime) determine the current platform and make some addition changes to the UI, while share the majority of it. And why not - there are plenty cross-platform components already.

I think it depends on a app and developer preferences - it's totally doable to maintain one file and either do the checks in runtime or utilise power of macroses and build two JS output based on compilation settings (e.g. :closure-defines {"app.config.platform" "ios"}, etc.)

[drapanjanas]

@artemyarulin thanks for pointing out alternatives! I'm actually open for improvements of current re-natal "hello world" app. Though, I do not have any problems with existing approach having separate core.cljs for iOS and android, so I will not spend time on this.

[artemyarulin]

I'm not saying that there is any problems with re-natal - it's completely fine and I like it. It's should be up to developer to solve those issue

[drapanjanas]

Sure Artem, totally agree! Thanks again for involvement and sharing your knowledge! :)

[olivergg]

@drapanjanas @artemyarulin Thank you both for the detailed explanation

[drapanjanas]

@artemyarulin looks like in current re-natal build setup you actually need to do platform checks at runtime... I have found issue #19 which causes failure in latest luno example app. Maybe you somehow solved this in your ktoa project? My initial (wrong) assumption was that separated iOS and android code so is not even evaluated on wrong platorm.

[drapanjanas]

Sorry, false alarm, I figured it out. The problem in luno app was caused by requiring platform specific namespace from shared namespace.