Fork me on GitHub
#cljsrn
<
2015-12-03
>
nodename00:12:40

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

nodename00:12:00

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

mfikes00:12:21

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

mfikes00:12:28

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

nodename00:12:54

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

mfikes00:12:42

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

mfikes00:12:31

(You may be seeing a Closure error.)

nodename00:12:34

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

mfikes00:12:22

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

nodename00:12:43

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

nodename00:12:50

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

mfikes00:12:33

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

nodename00:12:57

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

nodename00:12:21

is htis about natal or about omnext itself?

mfikes00:12:17

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

nodename00:12:54

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

mfikes00:12:19

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

nodename00:12:36

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

mfikes00:12:52

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

nodename00:12:04

@mfikes: exclude dep, will try that, thanks

mfikes00:12:06

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

nodename00:12:50

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

gphilipp21:12:00

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.

anmonteiro21:12:28

@gphilipp: I had some troubles with that as well

anmonteiro21:12:45

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

anmonteiro21:12:49

it didn't work out

anmonteiro21:12:09

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

anmonteiro21:12:08

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

gphilipp21:12:43

Do you have a code snippet I could look at ?

anmonteiro21:12:35

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

gphilipp21:12:54

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

gphilipp21:12:22

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)
                                           }}))))

anmonteiro21:12:25

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

anmonteiro21:12:36

esp. when you have more deeply nested components

anmonteiro21:12:21

quite a workaround heh

gphilipp21:12:57

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

gphilipp21:12:03

props in HomeComponent is nil

gphilipp21:12:39

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

anmonteiro21:12:01

oh but that is Om Next related

iamjarvo21:12:15

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

gphilipp21:12:00

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

iamjarvo21:12:26

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

iamjarvo21:12:59

are there logs for this slack?

noonian21:12:01

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

noonian21:12:22

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

gphilipp21:12:41

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

johanatan22:12:42

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.

johanatan22:12:41

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

anmonteiro22:12:50

@gphilipp: pass it as a computed prop

anmonteiro22:12:15

look at lines 39-40

anmonteiro22:12:38

:render-scene is a function

anmonteiro22:12:44

with args [route navigator]

gphilipp22:12:05

aw.. didn’t see that

anmonteiro22:12:09

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

anmonteiro22:12:00

it's how I learned to use the navigator

gphilipp22:12:11

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

johanatan22:12:35

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