Can anyone explain this business of set!ting js/React before and/or after :requiring om.next? set!ting it at all in my code gives an error at compilation time: ERROR: JSC_CONSTANT_REASSIGNED_VALUE_ERROR. constant React assigned a value more than once. Original definition at file:/Users/alan/.m2/repository/cljsjs/react/0.14.0-0/react-0.14.0-0.jar!/cljsjs/react/common/react.ext.js:11 at /Users/alan/Workspaces/Clojure/AwesomeProject/target/cljsbuild-compiler-0/hello/core.js line 5 : 0

And does it depend on which alpha of Om is in use?

@nodename: it was required previously (and still exists in the earlier documentation, and explained a bit there). With the latest Om it is no longer required (and is being removed from Natal)

I personally don't yet have a whole lot of experience with other than :none though…

@mfikes what does :none have to do with it?

@nodename: are you using :simple or :advanced? Guessing based on JSC_ …

(You may be seeing a Closure error.)

@mfikes: actually in this example using :advanced, yes

It may be the case that things don't yet work that way. Haven't tried myself....

Worked fine as a plain cljs app without Om with (def React (js/require “react-native”)

@mfikes: so with alpha 22 or maybe 24, set! js/React is not needed either before or after the require, is that right?

In the latest Natal, it is needed only after the ns form.

not using natal on all projects, need to break it down

is htis about natal or about omnext itself?

Natal just sets things up... So it is a general issue

yeah I need to see this working on ios and android ya see

@nodename: Perhaps you can exclude the extra (cljsjs) React dep that Om is pulling in.

@mfikes: yeah with :none the compiler message went away, thanks

Cool. Closure may be simply pointing out something that is not compatible with it (but yet happens to work).

@mfikes: exclude dep, will try that, thanks

@nodename: Cool. If you make advance a on that front, share it with us. :)

@mfikes: oh yeah, will return soon with a new raft of problems, will advise

I think that navigator-ios doesn’t play nice with om/next as it bypasses the query mechanism. It relies on passing down the props to the components it instantiates itself.

@gphilipp: I had some troubles with that as well

I could never pass props because Om Next props are not JS objects

it didn't work out

I know @iamjarvo was also trying to get it to work

didn't investigate much further as well, as I ended up using the Navigator that React Native developed from scratch

Do you have a code snippet I could look at ?

https://gist.github.com/anmonteiro/dbb34debe608b4470cba

(might be outdated, this is from almost a month ago!)

thx. Regarding navigator-ios, I can pass props, but it’s quite convoluted

clojure
(defui WidgetComponent
    static om/IQuery
    (query
        [this]
        '[:accounts :person])
    Object
    (render
        [this]
        (let [props (om/props this)
              _ (println "props in WidgetComponent:" props)]
            (navigator-ios {:style {:flex 1}
                            :initialRoute {:component HomeComponent
                                           :passProps (clj->js props)
                                           }}))))

right

not sure if clj->js won't break certain data structs

esp. when you have more deeply nested components

https://gist.github.com/gphilipp/5c50c3208d95711eccd4

oh wow

quite a workaround heh

😛

yeah 😞

passProps in HomeComponent has the data I got from the Query in WidgetComponent

props in HomeComponent is nil

scratch that, (om/props this) in HomeComponent is nil, but (.-props this) is not !

oh but that is Om Next related

@gphilipp: i might have the same problem. the solution right now is to use .-props

Yeah, I wondered why you didn’t use om/props when reading your code, until I got bitten by this issue 😛

i want to debug it but i need to get dig into om.next first

are there logs for this slack?

all om props are passed in a single prop of the actual react component I believe

is the navigator-ios component a regular react component that you could render as a sub-component?

@anmonteiro: in your code, how would you get a reference to the navigator inside the WidgetComponent ?

Why do you guys need a 'navigator' anyway? I just used a :screen entry in app-state and a change-screen fn utilizing a mapping from screen kwd to rendering function for said screen.

[`change-screen` could either clear the previous screen data on change or preserve it]

@gphilipp: pass it as a computed prop

how so ?

look at lines 39-40

:render-scene is a function

with args [route navigator]

aw.. didn’t see that

thx !

so just pass it as widget-component (om/computed {} {:navigation navigator})

this is also useful (although it's in JS): https://github.com/facebook/react-native/tree/master/Examples/UIExplorer/Navigator

it's how I learned to use the navigator

@johanatan: so you can get native like navigation (smooth swipe transitions, nav bar…)

Ahh, I see. That didn't apply in my case as the app I was cloning didn't have those.

@iamjarvo: Logs here http://clojurians-log.mantike.pro/cljsrn

thanks @mfikes